Caso de uso — Banco mediano sin HA sobre IBM i

Contexto

Industria: banca de retail mediana, ~150 sucursales. Plataforma: IBM Power S922 con IBM i 7.4 TR9. Una LPAR productiva única para core bancario, otra para batch nocturno. Aplicativo crítico: core bancario propietario en RPG IV / DB2 for i, con ~3 TB de datos productivos. Window operativa 24×6 (domingos noche con ventana acotada para mantenimiento). Equipo: dos administradores de IBM i de larga trayectoria, un DBA, infra externalizada.

Situación inicial (síntoma)

El banco está pasando una auditoría regulatoria. El auditor observa que:

1. •No hay un plan de continuidad operativa probado sobre el core bancario.
2. •El sitio principal es único — sin DR remoto.
3. •El backup nocturno con BRMS sobre cinta tarda 6 horas y crece cada año.
4. •La última prueba de restore fue hace 18 meses y no se documentó.

El CIO escala el tema y pide propuestas. Comercial llega via referido con una conversación corta: "Tenemos que demostrar continuidad ya. ¿Qué nos podés ofrecer?".

Discovery con preventa

Preguntas calificadoras aplicadas

(Ver Quick EDD — Para Comercial.)

| Pregunta | Respuesta del cliente | |---|---| | ¿Tienen RTO y RPO definidos? | RTO 4 horas, RPO 30 minutos (definidos por riesgo regulatorio). | | ¿Tienen sitio secundario? | Sí, un data center en otra ciudad para infraestructura corporativa, sin IBM i hoy. | | ¿Cuánto cuesta una hora de downtime? | ~50.000 USD según estimaciones internas. | | ¿Qué versión de IBM i y TR? | 7.4 TR9. | | ¿Están todos los objetos críticos journaled? | "Los principales sí, los nuevos del último release no estamos seguros." | | ¿Hay solución HA hoy? | No. | | ¿Db2 Mirror? | No, no la conocen. | | ¿Qué hardware tienen disponible para target? | Hay un Power S914 nuevo en sitio secundario, asignado al proyecto. |

Datos técnicos relevados

• •Power S922 productivo, 4 cores activos, 256 GB RAM, storage interno SAS + IASP de 1 TB.
• •Power S914 en sitio secundario, 4 cores, 128 GB RAM, storage interno SAS.
• •Conectividad entre sitios: enlace MPLS de 100 Mbps con latencia ~12 ms.
• •Volumen de cambios: ~5 GB de receivers/día.
• •Bibliotecas productivas: 12, suman ~3 TB.

Hallazgos críticos

• •Journaling parcial — varias tablas críticas del último release no quedaron journaled.
• •Sin HA documentado.
• •Ventana de backup creciente que ya está rozando el corte operativo.

Solución propuesta

Arquitectura

Quick EDD HA + DR combinado:

• •Source: Power S922 (sitio principal).
• •Target HA local: ninguna LPAR adicional en sitio principal — se omitió por costos. (En segunda iteración, se podría sumar.)
• •Target DR remoto: Power S914 (sitio secundario), recibiendo replicación lógica desde el source vía MPLS.
• •Topología: 1 → 1 (DR remoto único), futuro upgrade a 1 → 2 con HA local.

Productos en scope

• •Assure Quick EDD sobre source y target.
• •BRMS existente en source — sigue como está.
• •(Recomendación adicional: evaluar Flash For i en una segunda fase para resolver la ventana de backup nocturna sin afectar el core. No incluido en esta propuesta inicial para mantener foco.)

Sizing

• •Storage adicional para receivers en source: +200 GB con política de retención de 7 días.
• •CPU/memoria en target: suficiente para apply en régimen normal, monitoreado.
• •Ancho de banda: 100 Mbps con headroom; 5 GB/día en horas pico = ~10 minutos de transferencia, OK con margen.
• •RTO objetivo: < 30 minutos con switch automatizado.
• •RPO objetivo: < 1 minuto en condición normal.

Plan de implementación (alto nivel)

1. •Fase 0 — Saneamiento previo (4 semanas)
   • •Relevamiento exhaustivo de objetos por biblioteca productiva.
   • •Iniciar journaling sobre todos los objetos productivos faltantes (STRJRNPF — ver Lab Journaling).
   • •Política de retención de receivers definida.
2. •Fase 1 — Instalación y carga inicial (3 semanas)
   • •Instalación Quick EDD source + target.
   • •Configuración de grupos de replicación por biblioteca.
   • •Carga inicial completa source → target.
3. •Fase 2 — Operación regular y tuning (2 semanas)
   • •Quick EDD operando, monitoreo de lag.
   • •Ajustes de paralelismo y subsystems.
   • •Auditorías programadas.
4. •Fase 3 — Drill de switch (1 semana)
   • •Drill de role-swap controlado (ver Lab Role-Swap).
   • •Validación end-to-end.
   • •Documentación del procedure final.
5. •Fase 4 — Pase a producción + handover (2 semanas)
   • •Operación supervisada.
   • •Capacitación del equipo del cliente (track soporte L1 + senior).
   • •Plan de drills periódicos (trimestral).

Tiempo total estimado: 12 semanas.

Riesgos y mitigaciones

| Riesgo | Mitigación | |---|---| | Journaling incompleto detectado a último momento | Fase 0 dedicada explícitamente a esto, con freeze de releases hasta cerrar | | Ancho de banda insuficiente en picos extraordinarios | Política de QoS sobre el enlace + monitoreo proactivo | | Equipo del cliente sin experiencia en role-swap | Drill obligatorio antes de ir a producción + capacitación incluida | | Aplicación con dependencia de IPs hardcodeadas | Relevar y proponer reverse-DNS o capa de servicio antes del swap |

Resultado al cierre del proyecto

• •RPO real medido: < 30 segundos en operación normal.
• •RTO en drill de role-swap controlado: 22 minutos end-to-end (incluyendo validación de aplicación).
• •Auditoría regulatoria aprobada con la evidencia del drill documentada.
• •Reducción del riesgo financiero: 50.000 USD/h de downtime evitado en cualquier incidente que requiera DR.

Lecciones para preventa (qué dejar sin decir hasta que pregunten)

• •No hablar de pricing en discovery — eso es para la propuesta formal.
• •Anticipar la pregunta sobre journaling — es típico que parte del parque no esté journaled, y eso impacta cronograma.
• •Vender el drill como entregable, no como nice-to-have. Es el evento que valida que el cliente "tiene HA real".
• •Sembrar Flash For i para la fase 2 — la ventana de backup que ya rozan es un dolor que se resuelve con M81. No empujar en esta venta para no diluir.

Productos relacionados en el portafolio

• •Quick EDD — solución central de este caso.
• •Flash For i — venta secundaria para la ventana de backup (segunda fase).
• •Connect CDC — eventual, si el banco quiere modernizar reportería con un data lake. No es prioridad ahora.

Recursos

• •Módulo Quick EDD
• •Lab Quick EDD básico
• •Lab Role-swap
• •Runbook Quick EDD