Desarrollo1 día

Módulo 6 — Flash For i

Solución de M81 que automatiza FlashCopy/SnapShot del storage externo desde IBM i, para backups con downtime mínimo, dev/test y refresh de data warehouse.

Conocer **Flash For i** de **M81** como solución que automatiza la integración entre IBM i y los servicios de **FlashCopy / SnapShot** de los storage arrays externos, permitiendo backups del sistema con downtime mínimo y la creación de partition clones para usos secundarios.

Base común — todos los roles

Quién es M81

M81 es un ISV francés especializado exclusivamente en la plataforma IBM i. La empresa se posiciona como un vendor de productos de "sistema y tecnología" para IBM i, con foco en automatización, backups sin impacto en producción y monitoreo. Su escala actual habla de más de 800 instalaciones de Flash for i y más de 900 instalaciones de Control for i en más de 26 países, con más de 750 clientes finales y más de 1.600 LPARs gestionadas. La empresa publica entre 3 y 4 actualizaciones de producto por año y se distingue por un soporte técnico de respuesta rápida.

El portafolio de M81 para IBM i incluye:

  • •Flash for i — automatización de FlashCopy/SnapShot (foco de este módulo).
  • •Control for i — conecta los eventos del log de IBM i a herramientas generales de monitoreo, con más de 200 controles plug & play compatibles con Nagios, PRTG y similares.
  • •Recover for i — backup continuo basado en journaling local.

Qué es Flash for i

Flash for i gestiona, automatiza, controla y reporta todas las operaciones de FlashCopy (IBM Storage: DS8000, FlashSystem, SVC, Storwize) y SnapShot (otros arrays como EMC VMAX/PowerMax/Unity y PureStorage) sobre el storage externo, desde las propias LPARs de IBM i, usando comandos IBM i nativos.

La pieza central es el comando FLCLONE, que desde la partición productiva desencadena todo el proceso de clonado: quiesce del storage, disparo del FlashCopy, arranque de la partición clon y ejecución de las tareas configuradas sobre esa copia. El operador no necesita acceder al storage o al HMC directamente — Flash for i orquesta las conexiones seguras con esos componentes de forma transparente.

Los discos del clon aprovechan la naturaleza de las tecnologías FlashCopy/SnapShot: utilizan solo entre el 5 y el 15 % del espacio del disco original en el momento de la copia, y crecen solo con los bloques que divergen desde ese punto. Esto elimina la necesidad de duplicar el storage completo para tener un clon funcional.

Cómo se inserta en la operación

El flujo completo tiene cuatro fases automatizadas por Flash for i:

  1. •Quiesce del source — se ejecuta el comando CHGASPACT sobre la partición productiva para vaciar la memoria caché a disco y garantizar consistencia del punto en el tiempo antes del snapshot. Esta es una operación rápida que no detiene la aplicación.
  2. •FlashCopy / SnapShot — se dispara el grupo de consistencia en el storage externo. Los volúmenes presentados a la partición clon se convierten en copias exactas e independientes del estado productivo en ese instante.
  3. •Arranque del clon — Flash for i contacta el HMC (o NovaLink) para iniciar la LPAR clon. Antes de que la partición quede activa, Flash for i la hace "inofensiva": detiene los auto-jobs, cambia la IP, ajusta los parámetros del entorno para que no interfiera con producción.
  4. •Ejecución de tareas sobre el clon — por ejemplo, SAVE21 completo, backup incremental, refresh de ambiente de test, o extracción de datos para ETL.

Al finalizar, Flash for i reintegra el log de operaciones a la partición productiva (que puede ser BRMS u otro catálogo) y puede detener la partición clon si ya no se necesita.

Promesa cuantificada

Para entornos IBM i ocupados, un SAVE21 completo puede completarse con apenas dos minutos de downtime sobre la producción. Ese tiempo corresponde al quiesce + FlashCopy, que típicamente tarda alrededor de dos minutos. El backup en sí — que puede durar horas sobre un sistema grande — se ejecuta sobre la partición clon mientras producción opera normalmente con usuarios activos.

El impacto en producción se limita a esos minutos del quiesce inicial. En instalaciones donde el backup nocturno ya no entra en la ventana operativa o el sistema opera 24×7, esta reducción es el argumento técnico central.

Usos del clon (no solo backup)

El clon point-in-time tiene múltiples usos más allá del backup nocturno:

  • •Ambientes de test y desarrollo con datos productivos reales — sin copias manuales que tardan horas.
  • •Validación de upgrades, parches, scripts, migraciones antes de tocar producción.
  • •ETL / refresh de data warehouse desde una copia consistente de producción, sin impacto en los usuarios.
  • •Anonimización para cumplimiento de GDPR y CCPA — el clon puede tener datos sensibles substituidos antes de exponerse al equipo de desarrollo.
  • •Generación de múltiples copias simultáneas para diferentes equipos (rollback, compliance, analytics).

Posicionamiento frente a HA

Flash for i no reemplaza una solución de HA como Assure Quick EDD ni un esquema de DR remoto. Es complementario: cubre el problema del backup window y la disponibilidad de un clon point-in-time sobre el mismo data center. La combinación Flash for i + Quick EDD + BRMS es coherente y cubre capas distintas: backup eficiente, HA/DR remoto y gestión de medios.

DesarrolloPara Desarrollo (1 día)

Objetivo del rol en este módulo: automatizar e integrar Flash for i en pipelines.

Scripting alrededor del producto

  • •Wrappers en CL/Bash para encadenar Flash for i con otros pasos.
  • •Programar disparos fuera del esquema diario (p.ej. clon adicional para refresh de test bajo demanda).
  • •Coordinación con scheduler corporativo (no solo job scheduler IBM i).

Integración con pipelines de datos

  • •Si el cliente alimenta un data warehouse desde IBM i sin tocar producción, el clon Flash for i puede ser la fuente.
  • •Coordinación con pipelines de Connect CDC: el clon como punto de re-sincronización tras incidentes.

Wrapper CL para FLCLONE con manejo de errores

PGM
  DCL VAR(&ERRFLAG) TYPE(*LGL) VALUE('0')
  DCL VAR(&MSGID)   TYPE(*CHAR) LEN(7)
  DCL VAR(&MSGDTA)  TYPE(*CHAR) LEN(256)

  /* Notificar inicio del ciclo */
  SNDMSG MSG('Flash for i: Ciclo iniciado ' *CAT +
             %CHAR(%TIMESTAMP())) TOUSR(QSYSOPR)

  /* Ejecutar FLCLONE con monitoreo de errores */
  MONMSG MSGID(CPF0000 MCH0000 FLC0000) EXEC(DO)
    RCVMSG MSGTYPE(*EXCP) MSGID(&MSGID) MSGDTA(&MSGDTA)
    CHGVAR VAR(&ERRFLAG) VALUE('1')
    /* Notificar fallo */
    SNDMSG MSG('Flash for i: FALLO en ciclo. Error=' +
               *CAT &MSGID *TCAT ' ' *CAT &MSGDTA) +
           TOUSR(QSYSOPR)
    /* Enviar alerta a data queue para monitoreo externo */
    CALL PGM(MYLIB/SNDALERT) PARM('FLASH_FAIL' &MSGID &MSGDTA)
    GOTO CMDLBL(FIN)
  ENDDO

  FLCLONE CLONEDEF(PROD_NIGHTLY) ACTION(*EXECUTE)

  /* Verificar resultado */
  IF COND(&ERRFLAG *EQ '0') THEN(DO)
    SNDMSG MSG('Flash for i: Ciclo completado exitosamente ' +
               *CAT %CHAR(%TIMESTAMP())) TOUSR(QSYSOPR)
    /* Registrar éxito en data queue de monitoreo */
    CALL PGM(MYLIB/SNDALERT) PARM('FLASH_OK' '       ' '       ')
  ENDDO

FIN:
ENDPGM

El wrapper agrega lo que FLCLONE solo no hace: notificación al inicio, captura de errores con detalle del código, envío de alerta a un sistema externo, y confirmación de éxito. El programa SNDALERT sería un componente propio del cliente que envía la alerta a Zabbix/Nagios/Datadog/ServiceNow.

Integración con scheduler

Opción 1 — Job scheduler nativo de IBM i (WRKJOBSCDE):

ADDJOBSCDE JOB(FLASHNITE) CMD(CALL PGM(MYLIB/FLASHWRAP)) +
           FRQ(*WEEKLY) SCDDATE(*NONE) SCDDAY(*MON *TUE *WED *THU *FRI) +
           SCDTIME('020000') JOBD(MYLIB/FLASHJOBD) +
           USER(FLASHUSR)

Esto programa el wrapper CL para ejecutarse a las 02:00 AM de lunes a viernes. El perfil FLASHUSR debe tener autoridad sobre FLCLONE y sobre los objetos del storage.

Para verificar la programación:

WRKJOBSCDE JOB(FLASHNITE)

Opción 2 — Scheduler externo (Control-M, TWS, AutoSys):

Si el cliente usa un scheduler corporativo, el disparo se hace típicamente vía:

  • •SSH al IBM i + ejecución de SBMJOB del wrapper CL.
  • •O bien un agente del scheduler corriendo en IBM i que ejecuta el comando directamente.

La clave es que el scheduler externo pueda capturar el return code: si el wrapper CL termina con MONMSG, el job retorna un código de error que el scheduler puede usar para disparar alertas o re-intentos.

Buenas prácticas

  • •Versionar la configuración de Flash for i.
  • •Probar trimestralmente el restore desde la cinta/VTL generada (no solo el backup).
  • •Logs centralizados — enviar el reporte del ciclo a la consola de monitoreo corporativa.

Recursos oficiales

Recursos relacionados

Lab

Lab — Ciclo completo Flash For i (snapshot + backup desde clon)

Disparar una FlashCopy desde IBM i, arrancar la LPAR clon, ejecutar SAVE21 y reintegrar el log a BRMS. Versión simplificada para laboratorio.