flash-for-i

Runbook — Flash For i

Los 10 incidentes más frecuentes en operación de Flash For i (M81), con síntoma, evidencia, primer paso y criterio de escalado.

Soporte L1Soporte Senior

Runbook — Flash For i

Estructura: síntoma, evidencia, diagnóstico inicial (L1), criterio de escalado.

Convenciones: ⚠️ = acción que puede afectar producción o backup.

RB-FFI-001 — FlashCopy / SnapShot no se disparó

Síntoma

Reporte diario de Flash for i muestra que el ciclo no se ejecutó. No hay clon disponible para backup.

Evidencia a recolectar

Flujo de diagnóstico inicial (L1)

  1. •

    Confirmar si el job de Flash for i corrió en su scheduler.

    WRKJOBSCDE JOB(FLASHFORI)

    → Reemplazar FLASHFORI con el nombre real del job schedulado en el cliente. Verificar la columna Last submission y Next submission. Si Last submission es anterior a lo esperado, el scheduler no lo ejecutó. Verificar también si el job está en estado HLD (retenido).

  2. •

    Buscar el job de Flash for i en el historial de jobs.

    WRKJOB JOB(FLASHFORI *ALL)

    → Lista las ejecuciones recientes. Si el job aparece en estado OUTQ (terminó), verificar el joblog. Si no aparece, no se ejecutó.

  3. •

    Revisar el joblog del último ciclo.

    DSPJOBLOG JOB(nombre_job_flash)

    → Buscar el primer mensaje con severidad 30 o mayor. Flash for i registra en el joblog cada etapa del ciclo (quiesce, snapshot, unquiesce). Si el joblog está incompleto, el job terminó abruptamente.

  4. •

    Verificar QSYSOPR durante la franja del intento.

    WRKMSG MSGQ(QSYS/QSYSOPR) SEQ(*NEW)

    → Buscar mensajes relacionados con el storage (mensajes de tipo CPA o mensajes del LIC sobre I/O errors) en la franja del intento.

  5. •

    Verificar el estado del storage externo desde la consola del array (FlashSystem, Pure Storage, etc.). El acceso a la consola de storage varía por vendor — consultar las instrucciones del cliente. Buscar alertas activas o jobs de FlashCopy fallidos.

Criterio de escalado

RB-FFI-002 — LPAR clon no arrancó (IPL fallido)

Síntoma

FlashCopy ejecutó OK, pero la partición clon no arrancó o quedó en estado anormal. Backup no se ejecutó.

Evidencia a recolectar

Flujo de diagnóstico inicial (L1)

  1. •

    Verificar el estado de la LPAR clon en HMC.

    En HMC: Systems Management → Servers → [servidor] → Partitions → La LPAR clon debe aparecer en estado Running. Si está en Not Activated, Error, o Failed, anotar el estado exacto.

  2. •

    Capturar el SRC del IPL fallido.

    En HMC: Systems Management → Servers → [servidor] → Partitions → [LPAR clon] → Reference codes → El SRC (System Reference Code) es un código hexadecimal de 8 caracteres que identifica la causa del fallo de IPL. Anotar el código completo — es el input primario para IBM Support.

    DSPSYSVAL SYSVAL(QABNORMSW)

    → Este comando se ejecuta en IBM i si la LPAR clon logró cargar el OS pero hay indicios de IPL anormal. Si el valor es 1, el sistema hizo un IPL anormal (ej. por power loss o fallo de hardware durante el IPL). Si es 0, el último IPL fue normal.

  3. •

    Verificar recursos disponibles en HMC para la LPAR clon.

    En HMC: Systems Management → Servers → [servidor] → Properties → System Processor/Memory → Confirmar que hay cores y memoria disponibles para asignar a la LPAR clon. Si el pool de recursos compartidos está al 100%, la LPAR clon no puede arrancar.

  4. •

    Verificar si hubo cambio en hardware o LPAR config reciente. → Consultar al equipo de infraestructura si hubo cambios en el servidor (upgrade de firmware, reconfiguración de particiones, mantenimiento de HMC) en las últimas 24 horas.

Criterio de escalado

RB-FFI-003 — SAVE21 / backup desde clon falló

Síntoma

Clon arrancó pero el backup falló. Mensaje en QSYSOPR del clon o en el reporte de Flash for i.

Evidencia a recolectar

Flujo de diagnóstico inicial (L1)

  1. •

    Verificar disponibilidad del medio de backup.

    WRKMEDIBRM

    → Este comando (en la LPAR clon) muestra el estado de los medios BRMS. Buscar medios con estado AVL (available). Si no hay medios disponibles, el backup no puede ejecutarse.

    WRKMLMBRM MLM(*ALL)

    → Lista las media libraries (VTL o física). Verificar que la library está ONLINE y tiene cartuchos disponibles.

  2. •

    Verificar el joblog del SAVE21 en el clon.

    DSPJOBLOG JOB(nombre_job_save) OUTPUT(*PRINT)

    → Buscar mensajes OPT1132 (tape device not ready), CPF370C (no media available), o mensajes de BRMS como BRM1957 (media pool exhausted). El mensaje específico determina la causa raíz.

  3. •

    Verificar conectividad del clon al drive de backup.

    WRKDEVD DEVD(*TAP)

    → Lista las tape devices configuradas. El status debe ser AVAILABLE. Si dice VARIED OFF o FAILED, el drive no está accesible desde el clon.

  4. •

    Buscar errores específicos en QSYSOPR del clon.

    WRKMSG MSGQ(QSYS/QSYSOPR) SEQ(*NEW)

    → Buscar mensajes con severidad 40+ durante la franja del backup fallido.

Criterio de escalado

RB-FFI-004 — Reintegración del log a BRMS falló

Síntoma

Backup completó en el clon pero el log no se reintegró a BRMS de producción. Catálogo BRMS desactualizado.

Evidencia a recolectar

Flujo de diagnóstico inicial (L1)

  1. •

    Verificar el catálogo BRMS en producción.

    WRKMEDIBRM

    → Ejecutar en la LPAR de producción (no en el clon). Verificar si los medios del último backup del clon aparecen con el estado correcto. Si el catálogo no refleja el backup reciente, la reintegración no ocurrió.

    GO BRMS

    → Opción 1 (Backup) → Opción 8 (Work with media information). Buscar la fecha del último backup registrado. Si la fecha es anterior al ciclo que falló, confirma que la reintegración no se completó.

  2. •

    Verificar si la reintegración falló por autoridad.

    DSPUSRPRF FLASH_PROFILE

    → Reemplazar FLASH_PROFILE con el nombre real del perfil que ejecuta Flash for i. Verificar que tiene autoridad *USE sobre los objetos de BRMS y *ALLOBJ si es necesario según el diseño del cliente. Un error CPF2204 o CPF2189 en el joblog indica problema de autoridad.

  3. •

    Verificar si BRMS estaba en uso por otro job al momento de la reintegración.

    WRKOBJLCK OBJ(QBRM/Q1ABRMSEC) OBJTYPE(*FILE)

    → Si hay locks exclusivos activos sobre los archivos de catálogo de BRMS, otro job estaba usando BRMS y bloqueó la reintegración. Identificar el job que tiene el lock.

  4. •

    Verificar integridad del log generado en el clon. → El reporte de Flash for i incluye la ruta donde el clon genera el log de reintegración. Verificar que el archivo fue creado y tiene contenido válido.

Criterio de escalado

RB-FFI-005 — FlashCopy ejecuta pero rinde mucho menos de lo esperado

Síntoma

La FlashCopy que históricamente tardaba ~segundos ahora tarda minutos. Impacta la ventana operativa.

Evidencia a recolectar

Flujo de diagnóstico inicial (L1)

  1. •

    Verificar espacio del pool de target en storage.

    Acceder a la consola del storage (FlashSystem, Pure, etc.) y verificar el % used del pool donde se crean los snapshots. Si el pool supera el 80% de capacidad, el storage puede estar usando Copy-on-Write mode en lugar de FlashCopy real, lo que degrada el rendimiento significativamente.

  2. •

    Verificar utilización del sistema IBM i durante el ciclo de FlashCopy.

    WRKSYSACT

    → Si la CPU o el I/O están saturados durante el ciclo, la comunicación entre Flash for i y el storage se puede demorar. CPU sostenida >80% durante el snapshot es un indicador.

    WRKDSKSTS

    → Verificar I/O rate y response time de disco. Response times mayores a 50 ms indican contención en el storage.

  3. •

    Verificar si hubo firmware update reciente del storage. → Un firmware update del storage puede cambiar el comportamiento del FlashCopy. Documentar la versión antes y después del cambio.

  4. •

    Verificar otras FlashCopies simultáneas. → En la consola del storage, verificar si hay otras FlashCopies activas al mismo tiempo. La contención entre FlashCopies comparte el ancho de banda del storage.

Criterio de escalado

RB-FFI-006 — Storage externo cambia versión / firmware

Síntoma

Tras un upgrade del storage (FlashSystem, EMC, etc.), Flash for i empieza a fallar o comportarse distinto.

Evidencia a recolectar

Flujo de diagnóstico inicial (L1)

  1. •

    Documentar el upgrade con precisión. → Solicitar al equipo de storage la versión de firmware anterior y la nueva. Anotar la fecha y hora del upgrade.

  2. •

    Verificar la matriz de compatibilidad de M81. → Acceder a m81.eu/flash-for-i y descargar la matriz de compatibilidad vigente. Buscar la fila correspondiente al modelo de storage del cliente y verificar que la nueva versión de firmware está certificada.

  3. •

    Capturar los errores específicos en los logs de Flash for i.

    DSPJOBLOG JOB(nombre_job_flash) OUTPUT(*PRINT)

    → Buscar mensajes que indiquen fallo de comunicación con el storage, errores de API del storage, o mensajes del tipo "unsupported operation" o "feature not available". Estos mensajes son clave para el case con M81.

  4. •

    Notificar al senior.

Criterio de escalado

(Verificar matriz vigente con M81 — referencia: m81.eu/flash-for-i)

RB-FFI-007 — Inconsistencia en el clon (datos no coinciden con producción)

Síntoma

Validaciones esporádicas detectan que el clon no representa producción al momento del snapshot. Causa típica: la captura de la FlashCopy no encontró un punto consistente.

Evidencia a recolectar

Flujo de diagnóstico inicial (L1)

  1. •

    Verificar el indicador de IPL anormal en el clon — un clon inconsistente puede haber arrancado con IPL anormal.

    DSPSYSVAL SYSVAL(QABNORMSW)

    → Ejecutar en la LPAR clon. Si el valor es 1, el clon arrancó en modo de recuperación (IPL anormal), lo que significa que al momento del snapshot había transacciones activas sin commit. Esto es esperado en algunos diseños (el OS recupera al arrancar), pero si el proceso de recuperación encuentra inconsistencias, Flash for i debería haberlo detectado.

  2. •

    Verificar configuración de quiesce / preparación previa al snapshot. → El reporte de Flash for i muestra las etapas del ciclo. La etapa de quiesce detiene brevemente la aplicación para garantizar un punto consistente. Si el quiesce no está configurado o falló, el snapshot puede contener transacciones a medias.

  3. •

    Verificar si hubo transacciones largas abiertas al momento del snapshot.

    En producción, cerca del horario del snapshot:

    WRKLCKOBJ

    o

    WRKACTJOB SBS(QINTER) OUTPUT(*PRINT)

    → Si hay transacciones que llevan más de N minutos abiertas al momento del snapshot, el clon puede no ser consistente a nivel de aplicación (aunque sí a nivel de storage si el quiesce funcionó).

Criterio de escalado

RB-FFI-008 — Sin espacio para snapshot en pool del storage

Síntoma

FlashCopy falla por "out of space" o "no available capacity" en el pool de target del storage.

Evidencia a recolectar

Flujo de diagnóstico inicial (L1)

  1. •

    Verificar uso del pool en la consola del storage.

    Acceder a la consola del storage y navegar al pool de FlashCopy. Verificar el porcentaje usado. Si supera el 90%, es probable que el nuevo snapshot no tenga espacio.

  2. •

    Verificar snapshots vigentes que se pueden purgar.

    En la consola del storage: buscar la lista de FlashCopy sessions / volumes activos. Si hay snapshots de días anteriores que la política dice que ya no son necesarios, coordinar con el equipo de storage para purgarlos.

  3. •

    Verificar la política de retención configurada en Flash for i. → El reporte de Flash for i o la configuración del producto indica cuántos snapshots se retienen. Si la política dice "retener 7 días" pero el storage solo tiene espacio para 3, hay un desbalance que el senior debe resolver.

  4. •

    Coordinar con storage para purga / ampliación.

Criterio de escalado

RB-FFI-009 — Conflicto con HA (Quick EDD activo en source)

Síntoma

Cuando coexisten Quick EDD activo y Flash for i sobre el mismo source, surgen comportamientos inesperados (Quick EDD reporta lag puntual durante la FlashCopy, o el clon presenta divergencias).

Evidencia a recolectar

Flujo de diagnóstico inicial (L1)

  1. •

    Verificar superposición temporal de operaciones.

    WRKJOBSCDE

    → Listar todos los jobs schedulados. Buscar si el ciclo de Flash for i (FlashCopy + quiesce) se superpone con ciclos de auditoría de Quick EDD o con ventanas de alta actividad de replicación. Documentar los horarios exactos de ambas operaciones.

  2. •

    Verificar lag de Quick EDD durante la franja de FlashCopy.

    WRKACTJOB SBS(QEDDSBSYS)

    → Si los jobs de Quick EDD muestran DEQW (wait) durante la FlashCopy, el quiesce de Flash for i está impactando la replicación. Anotar la duración del impacto.

  3. •

    Documentar el comportamiento con timestamps y escalar.

Criterio de escalado

RB-FFI-010 — Falla recurrente sin patrón claro

Síntoma

Ciclos individuales fallan de forma aparentemente aleatoria. No hay un único punto de falla evidente.

Evidencia a recolectar

Flujo de diagnóstico inicial (L1)

  1. •

    Recolectar y correlacionar evidencia de los últimos 30 ciclos.

    WRKJOB JOB(FLASHFORI *ALL)

    → Lista las ejecuciones históricas. Para cada ciclo fallido, anotar la hora de inicio, la hora de fin, y el código de retorno. Buscar un patrón temporal (¿siempre falla a cierta hora?, ¿en días de semana específicos?).

  2. •

    Comparar los fallos con el change log de infraestructura. → Solicitar al equipo de IT el log de cambios (change control) para el período. Cambios en red, storage, OS, firmware, o aplicación que coincidan temporalmente con los fallos son candidatos a causa raíz.

  3. •

    Verificar la salud general del sistema durante los fallos.

    WRKDSKSTS
WRKSYSACT

    → Ejecutar durante o inmediatamente después de un fallo. Buscar indicadores de presión de recursos (CPU, disco, I/O).

  4. •

    Documentar el patrón temporal y toda la evidencia recolectada.

Criterio de escalado

Anexo — convenciones de escalado a M81

Cuando se abre un case con M81, incluir:

Plantilla de comunicación P1

Usar cuando el ciclo de FlashCopy falló y no hay backup disponible, o cuando la LPAR clon no arrancó y el ciclo de backup no se pudo ejecutar. Enviar por email y por el canal de guardia definido en el contrato del cliente.

ASUNTO: [P1] Flash For i — [cliente] — Ciclo sin backup disponible — [timestamp]

CLIENTE: [nombre]
PRODUCTO: Flash For i v[versión] (M81)
SERVIDOR: IBM i [hostname] — Modelo Power [modelo] — IBM i v[versión] TR[TR]
STORAGE: [FlashSystem / Pure / EMC / otro] — Firmware v[versión]
INICIO DEL INCIDENTE: [fecha y hora con timezone]
DETECTADO POR: [quién detectó — reporte automático / alerta / monitoreo]

IMPACTO:
- No hay backup disponible para la fecha de hoy.
- [Indicar si hay SLA de RPO comprometido con el cliente]
- Último backup exitoso: [fecha y hora]

ESTADO ACTUAL:
- Estado del job de Flash For i: [completó con error / no se ejecutó / LPAR clon no arrancó]
- Estado de la LPAR clon: [Running / Not Activated / Error / SRC: XXXXXXXX]
- Estado del storage: [normal / en alerta — descripción]
- DSPSYSVAL QABNORMSW en clon: [0 / 1 / no aplica porque la LPAR no arrancó]

ACCIONES YA EJECUTADAS:
- [Lista de acciones tomadas y resultados observados]

EVIDENCIA RECOLECTADA:
- [x] Joblog de Flash For i — adjunto
- [x] QSYSOPR producción franja del incidente — adjunto
- [x] Estado LPAR clon en HMC (screenshot) — adjunto
- [x] Estado del storage (screenshot de consola) — adjunto
- [ ] [Lo que aún falta]

PRÓXIMA ACCIÓN:
- Esperando instrucción de [senior / cliente / M81 Support]

CONTACTO GUARDIA SOPORTE SENIOR: [nombre y celular]
CONTACTO CLIENTE (técnico): [nombre y celular]
CONTACTO EQUIPO DE STORAGE: [nombre y celular]

Recursos relacionados