Módulo 6 — Flash For i

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.

Objetivo del rol en este módulo: diagnóstico avanzado, recovery, integración compleja.

Recovery desde un snapshot

• •Validación previa de integridad del snapshot.
• •Procedimiento de restore parcial (objetos, bibliotecas, IFS) desde el medio backup.
• •Procedimiento de restore completo (en escenario catastrófico).

Coordinación con HA

• •Cuándo combinar Flash for i con Quick EDD: backup desde el target de Quick EDD para reducir aún más el impacto en producción.
• •Riesgos de inconsistencia si el target de Quick EDD tiene apply lag al momento del snapshot.

Integración con BRMS

• •Validar consistencia del catálogo BRMS después de cada ciclo.
• •Manejo de medios: pool de tapes, VTL, expirations.

Performance y troubleshooting

• •Tiempo de FlashCopy elevado — verificar pool del storage, firmware, contention.
• •Tiempo de IPL del clon elevado — sizing de la LPAR clon.
• •Tiempo de SAVE21 elevado — paralelismo, drives múltiples, tipo de medio.

Procedimiento de recovery desde un snapshot

Cuando se necesita restaurar datos desde un backup generado por Flash for i, la secuencia es:

1. •Identificar el medio de backup (cinta/VTL) que contiene el SAVE21 del ciclo deseado. Consultar el catálogo BRMS: WRKMEDBRM TYPE(*BKU).
2. •Verificar que el medio esté disponible y legible. Si es cinta física, cargarla en el drive. Si es VTL, verificar que el volumen virtual esté accesible.
3. •Para restore parcial (objetos o bibliotecas específicas): RSTLIB SAVLIB(MYLIB) DEV(TAPMLB01) VOL(*MOUNTED) MBROPT(*ALL).
4. •Para restore completo del sistema (escenario catastrófico): seguir el procedimiento de recovery de IBM i con SAVSYS + SAVLIB desde el medio generado por el SAVE21 del clon.
5. •Verificar integridad de los datos restaurados contra los datos productivos.
6. •Si se restaura a un punto en el tiempo anterior, considerar el impacto sobre la replicación de Quick EDD (el target puede estar más adelante que el source restaurado).

Validación del catálogo BRMS

Después de cada ciclo, verificar que el catálogo BRMS refleja correctamente el backup:

WRKMEDBRM TYPE(*BKU)

Buscar la entrada correspondiente al último ciclo Flash for i. Verificar: fecha/hora correctas, volumen utilizado, estado del medio (ACTIVE, no EXPIRED), y que las bibliotecas esperadas estén listadas.

Para una validación más profunda:

WRKMEDIBRM

Verifica la integridad del inventario de medios: que no haya volúmenes huérfanos, que las expirations estén correctas, y que el pool de medios tenga espacio para los próximos ciclos.

Análisis de timing para identificar FlashCopy lento

Si el paso de FlashCopy toma más de 30 segundos, investigar:

1. •Pool de FlashCopy en el storage: verificar en la consola del storage (DS8000 CLI, FlashSystem GUI, SVC CLI) el porcentaje de uso del pool de target. Un pool >80% lleno degrada la performance del FlashCopy.
2. •Número de volúmenes en el consistency group: más volúmenes = más tiempo. Verificar si se puede optimizar agrupando LUNs.
3. •Firmware del storage: versiones de firmware antiguas pueden tener bugs o limitaciones de performance. Verificar contra las release notes del vendor.
4. •Contención con otros FlashCopies: si hay múltiples FlashCopies activas (ej. varios entornos de test), compiten por el pool de target.

Método de medición: comparar los tiempos del log de Flash for i (DSPFLLOG) de los últimos 30 ciclos. Si el tiempo de FlashCopy tiene tendencia ascendente, el pool de target se está llenando progresivamente.

Casos límite

• •Storage cambia de modelo o vendor → Flash for i debe re-validarse contra la nueva matriz de compatibilidad.
• •Migración a Power nuevo / firmware nuevo.
• •Cambios de versión de IBM i (parches que afectan IPL del clon).