Caso de uso — Industria con ventana de backup cerrada
Contexto
Industria: manufactura de bienes de consumo masivo. Operación 24×7 con tres turnos. Sin domingos libres por demanda estacional. Plataforma: IBM Power E1050 con IBM i 7.5 TR4. Core de producción, MES y trazabilidad sobre RPG + DB2 for i, ~8 TB. Storage: IBM FlashSystem 9100, conectado por Fibre Channel. Backup actual: BRMS sobre LTO9 con drive interno; SAVE21 nocturno + saves incrementales.
Situación inicial
El SAVE21 semanal dejó de entrar en la ventana:
- •Hace 18 meses tardaba 4 horas; hoy tarda 9 horas y media.
- •Se desbordó dos veces sobre el primer turno de producción, generando lentitud en el ERP y quejas formales.
- •Los saves incrementales también crecen.
- •Producción exige cero impacto en horario operativo. La gerencia industrial ya escaló a CIO.
El CIO pide solución. La conversación con preventa empieza así: "Necesito un SAVE21 sin afectar producción. Mi storage hace FlashCopy pero nadie lo coordina con IBM i.".
Discovery
Preguntas aplicadas
(Ver Flash For i — Para Comercial.)
| Pregunta | Respuesta | |---|---| | ¿Qué ventana de backup tienen y la siguen cumpliendo? | 6 horas nocturnas. Hace 6 meses la rebasaron por primera vez. Hoy es habitual. | | ¿Qué storage externo? | IBM FlashSystem 9100. | | ¿Tienen FlashCopy licenciado? | Sí, viene con el storage. Hoy se usa para snapshots manuales esporádicos. | | ¿Usan BRMS? | Sí, intensivamente. Catálogo bien organizado. | | ¿Cómo refrescan ambientes test/dev hoy? | Manual, tarda 1 día con downtime de producción de 30 min. Lo hacen 1 vez por trimestre y cuesta una pelea cada vez. | | ¿Tienen Quick EDD u otra HA? | No tienen HA hoy; está en evaluación pero no es prioridad inmediata. |
Datos técnicos relevados
- •IBM Power E1050, 16 cores activos, 512 GB RAM.
- •IBM i 7.5 TR4, BRMS al día, 8 TB en system ASP.
- •FlashSystem 9100, pool de target con espacio disponible para FlashCopies del system ASP.
- •LPAR clon NO existe — habría que crearla o licenciar CoD.
- •Drive interno LTO9 disponible; VTL en proyecto pero no operativa aún.
Solución propuesta
Arquitectura
[Power E1050 — Producción IBM i (LPAR A)]
|
| comandos IBM i
v
[Flash For i] -------- dispara --------> [FlashSystem 9100]
|
| FlashCopy
v
[LUNs clon]
|
v
[LPAR clon (LPAR B, en mismo Power)]
|
| SAVE21 (sin afectar prod)
v
[LTO9 interno]
|
| reintegración
v
[BRMS en LPAR A]
(Fuente arquitectura: M81 — Flash for i, IT Jungle — M81 Speeds Backups with Flash for i)
Productos en scope
- •Flash For i (M81) sobre la LPAR productiva.
- •LPAR clon a crear en el mismo Power.
- •BRMS + LTO9 existentes.
Diseño de la solución
- •LPAR clon: misma LPAR física Power E1050, recursos asignados solo durante el ciclo (4 cores y 64 GB de memoria liberables del pool compartido).
- •Política de retención de FlashCopies: 1 snapshot por ciclo, sobreescrito cada noche. Pool de target del FlashSystem dimensionado para 1 vez el ASP system de producción.
- •Cron del ciclo: 23:00 disparo, FlashCopy en segundos, IPL del clon, SAVE21 desde clon, reintegración a BRMS antes de las 03:00.
- •Downtime efectivo sobre producción: ~2 minutos (tiempo del FlashCopy + quiesce). (Fuente: IT Jungle)
Plan de implementación (alto nivel)
- •Fase 0 — Setup de infraestructura (2 semanas)
- •Crear LPAR clon en HMC con plantilla.
- •Configurar el pool de target en FlashSystem.
- •Validar conectividad LTO desde la LPAR clon.
- •Fase 1 — Instalación y configuración Flash For i (2 semanas)
- •Instalación en LPAR productiva.
- •Configuración del ciclo end-to-end.
- •Pruebas en horario diurno controlado.
- •Fase 2 — Validación funcional (2 semanas)
- •Ejecutar el ciclo completo en la ventana real.
- •Medir el downtime real.
- •Validar reintegración a BRMS.
- •Probar restore de muestra desde la cinta generada.
- •Fase 3 — Pase a producción + capacitación (2 semanas)
- •Operación supervisada.
- •Capacitación del equipo (track L1 + senior).
- •Runbook completo.
- •Fase 4 — Uso secundario del clon (en cuanto se estabilice)
- •Refrescar el ambiente de test/dev usando el mismo clon (con downtime cero adicional sobre producción).
Tiempo total estimado: 8 semanas.
Riesgos y mitigaciones
| Riesgo | Mitigación | |---|---| | LPAR clon sin recursos disponibles | CoD activable temporalmente o reasignación desde pool en horario nocturno | | Pool del FlashSystem se llena | Policy de purga + monitoreo proactivo | | BRMS rechaza la reintegración | Procedimiento validado en fase 2, perfil con autoridades correctas | | Restore real no probado | Drill de restore en fase 2 (parte del scope, no opcional) | | Firmware del FlashSystem cambia y rompe compatibilidad | Validar matriz de compatibilidad M81 antes del upgrade |
Resultado al cierre del proyecto
- •Downtime efectivo sobre producción medido: 2 minutos 10 segundos.
- •SAVE21 completo terminando antes de las 03:00 (3 horas de margen recuperadas en la ventana).
- •Refresh de ambiente test/dev pasó de "1 día con downtime" a "se hace cada noche, gratis".
- •Producción dejó de quejarse — caso cerrado para la gerencia industrial.
Lecciones para preventa
- •El cliente ya tiene el storage que hace FlashCopy — eso es 80% del trabajo de discovery. Si lo tiene, el caso es muy fuerte.
- •No vender Flash for i como "backup tool" — es un orquestador entre IBM i, HMC, storage y BRMS. Esa es la propuesta real.
- •El uso secundario del clon (test/dev/ETL) suele ser el "wow" del cliente cuando se demuestra. Reservalo para el cierre.
- •No canibalizar HA — si en algún momento el cliente quiere HA/DR, Quick EDD se vende además, no en lugar de.
- •Probar el restore es entregable — un backup que no se probó no existe. Es la parte que diferencia una propuesta seria.
Productos relacionados
- •Flash For i — central.
- •Quick EDD — eventual segunda venta cuando aparezca DR/HA en el roadmap del cliente.
- •Connect CDC — eventual: el clon Flash for i puede ser la fuente de un pipeline CDC sin tocar producción.