HA clustering, replicacion basada en journals, switchover y failover, PowerHA SystemMirror, Independent ASPs y patrones de arquitectura HA en IBM i.
Aunque IBM i es uno de los sistemas mas estables del mercado, la alta disponibilidad (HA) sigue siendo critica. No se trata solo de fallas de hardware — se trata de mantener el servicio durante mantenimiento planificado, actualizaciones de SO, aplicacion de PTFs y cambios de hardware.
Linux / x86
IBM i
Dos metricas fundamentales definen los requerimientos de disponibilidad:
RPO
Recovery Point Objective
Cuanta perdida de datos es aceptable. Un RPO de 0 significa cero perdida de datos. Un RPO de 1 hora acepta perder hasta 1 hora de transacciones.
RTO
Recovery Time Objective
Cuanto tiempo puede estar el sistema caido. Un RTO de 15 minutos exige que el servicio se restaure en ese lapso. Define la urgencia del failover.
La base de toda solucion de HA en IBM i es el journaling. Cuando una tabla esta bajo journaling, cada cambio (insert, update, delete) genera una entrada en el journal. La replicacion consiste en enviar esas entradas al servidor standby y aplicarlas para mantener una copia sincronizada.
Servidor PRODUCCION
Aplicaciones activas
INSERT, UPDATE, DELETE
Journal entries generadas
Servidor STANDBY
Copia de datos actualizada
Aplica journal entries
Listo para switchover
Las journal entries viajan del servidor de produccion al standby en tiempo real (asincrono) o con confirmacion (sincrono).
CRTJRNRCV JRNRCV(MILIB/RCVHA0001) THRESHOLD(1000000) Crear journal receiver con threshold de 1GB CRTJRN JRN(MILIB/JRNHA) JRNRCV(MILIB/RCVHA0001) MNGRCV(*SYSTEM) DLTRCV(*YES) Crear journal con gestion automatica de receivers STRJRNPF FILE(MILIB/CLIENTES) JRN(MILIB/JRNHA) IMAGES(*BOTH) OMTJRNE(*OPNCLO) Iniciar journaling en tabla CLIENTES *BOTH = guardar imagen before y after (necesario para HA) STRJRNPF FILE(MILIB/FACTURAS MILIB/DETALLE) JRN(MILIB/JRNHA) IMAGES(*BOTH) Journalear multiples tablas en un solo comando WRKJRNA JRN(MILIB/JRNHA) Ver atributos del journal DSPJRN JRN(MILIB/JRNHA) RCVRNG(*CURCHAIN) OUTPUT(*OUTFILE) OUTFILE(QTEMP/JRNDATA) Exportar entries del journal para analisis
IMAGES(*BOTH). Si solo se captura la imagen after, el producto de HA no podra resolver conflictos ni hacer rollback de transacciones incompletas durante un failover.IBM i tiene soporte nativo de remote journaling que permite enviar journal entries a un journal en otro sistema a traves de la red. Sobre esta base, los productos de HA construyen la logica de aplicacion de cambios en el destino.
ADDRMTJRN RDB(STANDBY01) SRCJRN(MILIB/JRNHA) TGTJRN(MILIB/JRNHA) Configurar remote journaling al sistema STANDBY01 Las entries del journal local se replican al journal remoto WRKRMTJRN Ver remote journals configurados CHGRMTJRN RDB(STANDBY01) SRCJRN(MILIB/JRNHA) DLVMOD(*ASYNC) Cambiar modo de entrega a asincrono RMVRMTJRN RDB(STANDBY01) SRCJRN(MILIB/JRNHA) Quitar remote journaling
Replicacion logica
Replica las operaciones (journal entries) y las aplica en el destino.
+Se seleccionan objetos especificos a replicar
+El destino puede tener estructura diferente
+Permite replicacion selectiva (solo ciertas tablas)
+Los datos en destino son accesibles durante replicacion
+Mas flexible para configuraciones complejas
+Requiere mas administracion para agregar objetos nuevos
Replicacion fisica (Geographic Mirroring)
Replica a nivel de paginas de disco. Toda escritura se copia al destino.
+Replica TODO sin seleccion (inclusive IFS, spool, etc.)
+Configuracion mas simple — no hay que elegir objetos
+Menor overhead de CPU en el destino
+El ASP replicado no es accesible hasta el switchover
+Requiere hardware compatible y misma version de SO
+Es la opcion mas cercana a DRBD/ZFS mirror de Linux
WRKRDBDIRE) y conectividad TCP/IP entre ellos. Las tablas en produccion deben estar bajo journaling con IMAGES(*BOTH).IBM i tiene Cluster Resource Services integrado al SO, y PowerHA SystemMirror for i es el producto licenciado que agrega Geographic Mirroring y herramientas avanzadas de gestion. Juntos proporcionan heartbeat entre nodos, deteccion de fallos, gestion de recursos y movimiento automatico de IPs.
Cluster nodes
Los sistemas IBM i que participan en el cluster. Cada nodo tiene un rol (primario, backup, replicado).
Cluster Resource Group (CRG)
Define que recursos se gestionan como grupo (datos, aplicaciones, dispositivos). Es la unidad de switchover.
Takeover IP address
Direccion IP flotante que se mueve automaticamente al nodo activo. Los clientes siempre se conectan a esta IP.
Exit programs
Programas CL que el cluster ejecuta durante switchover/failover para detener y arrancar aplicaciones.
Heartbeat
Mensajes periodicos entre nodos para verificar que estan activos. Si un nodo deja de responder, se inicia failover.
CRTCLU CLUSTER(MICLUSTER)
NODE((IBMI01 ('10.1.1.100')) (IBMI02 ('10.1.2.100')))
Crear cluster con dos nodos
ADDCLUNODE CLUSTER(MICLUSTER)
NODE(IBMI03) NETIFC(('10.1.3.100'))
Agregar un tercer nodo al cluster
STRCLUNOD CLUSTER(MICLUSTER) NODE(IBMI01)
Iniciar un nodo del cluster
ENDCLUNOD CLUSTER(MICLUSTER) NODE(IBMI01)
Detener un nodo del cluster
DSPCLURSC
Ver recursos del cluster
WRKCLU
Trabajar con cluster (ver nodos, estado, CRGs)
CHGCRGPRI CRG(MICRG)
Hacer switchover (cambiar nodo primario del CRG)Geographic Mirroring
Replicacion fisica a nivel de disco. Todo el contenido de un Independent ASP se replica en tiempo real al sitio remoto. RPO cercano a cero.
Metro Mirror
Replicacion sincrona para distancias cortas (< 300km). Cada escritura se confirma en ambos sitios antes de retornar al programa. RPO = 0.
Global Mirror
Replicacion asincrona para largas distancias. Las escrituras se agrupan y se envian periodicamente. Menor impacto en performance pero RPO > 0.
HyperSwap
Switchover transparente a nivel de storage para fallas de disco. Los servidores no detectan la interrupcion. Requiere storage DS8000 o FlashSystem.
Precisely iCluster
Replicacion logica journal-based. Muy usada en el mercado. Permite replicacion selectiva con monitoreo granular y switchover automatizado.
Precisely Assure MIMIX (Quick-EDD)
Otra solucion de replicacion logica con interfaz grafica avanzada, comparacion de objetos y gestion de switchover.
Maxava HA
Solucion de HA con enfoque en simplicidad. Usa remote journaling nativo con una capa de gestion y automatizacion.
Switchover (planificado)
Se inicia manualmente por el administrador.
El sistema de produccion detiene aplicaciones de forma ordenada.
Se verifica que la replicacion este al dia.
Se transfiere el rol primario al servidor standby.
La IP flotante se mueve al nuevo nodo activo.
Los usuarios reconectan (o se reconectan automaticamente).
Uso tipico: Mantenimiento planificado, aplicar PTFs, IPL
Failover (no planificado)
Se activa automaticamente cuando el nodo primario falla.
El cluster detecta la falla por perdida de heartbeat.
El servidor standby asume el rol primario inmediatamente.
Puede haber perdida de datos si la replicacion era asincrona.
Las aplicaciones se inician en el nodo de backup.
Requiere validacion post-failover del estado de los datos.
Uso tipico: Falla de hardware, desastre, caida no prevista
Verificar estado de replicacion
Confirmar que no hay lag y que todos los objetos estan sincronizados.
Notificar a usuarios
Avisar que habra una desconexion breve (tipicamente 5-15 minutos).
Detener aplicaciones
Terminar subsistemas de aplicacion, batch jobs y conexiones activas.
Ejecutar switchover
Iniciar el cambio de rol a traves del producto de HA o del cluster (CHGCRGPRI).
Verificar nuevo primario
Confirmar que las aplicaciones arrancaron y los usuarios pueden conectarse.
Mantener el sistema original
Aplicar PTFs, hacer IPL, reemplazar hardware segun se necesite.
Switchback
Cuando el mantenimiento termine, hacer switchover de vuelta al nodo original.
Los Independent Auxiliary Storage Pools (IASP) son una pieza fundamental de la alta disponibilidad en IBM i. Un IASP es un grupo de discos que se puede conectar y desconectar de un sistema de forma independiente, similar a un volumen o filesystem montable en Linux.
Encapsulacion de datos
Un IASP contiene bibliotecas, objetos IFS y journals como una unidad logica. Se puede mover completo entre sistemas.
Switchable IASP
En un cluster, un IASP switchable se puede traspasar de un nodo a otro. Los datos permanecen consistentes porque el IASP se varia off/on.
Geographic Mirroring
PowerHA puede replicar un IASP completo a otro sitio usando mirroring a nivel de pagina de disco. El IASP destino no es accesible hasta switchover.
Independencia del sistema
Las aplicaciones y datos en un IASP son portables. Si el servidor falla, otro nodo del cluster puede tomar posesion del IASP.
CFGDEVASP Menu de configuracion de ASPs (requiere SST o DST) SETASPGRP ASPGRP(33) Establecer el IASP activo para la sesion (ASP 33) VRYCFG CFGOBJ(IASP33) CFGTYPE(*DEV) STATUS(*ON) Activar (variar on) un IASP VRYCFG CFGOBJ(IASP33) CFGTYPE(*DEV) STATUS(*OFF) Desactivar (variar off) un IASP WRKDEVD *ASP Trabajar con dispositivos ASP DSPASPSTS ASP(33) Ver estado y uso de disco del IASP WRKSYSVAL SYSVAL(QSRTMEM) Ver el IASP por defecto del sistema
-- Ver estado de todos los ASPs del sistema
SELECT ASP_NUMBER, DEVICE_DESCRIPTION_NAME,
ASP_STATE, ASP_TYPE, TOTAL_CAPACITY,
USED_CAPACITY, PERCENT_USED
FROM QSYS2.ASP_INFO
ORDER BY ASP_NUMBER;
-- Ver bibliotecas en un IASP especifico
SELECT SCHEMA_NAME, ASP_NUMBER
FROM QSYS2.SYSSCHEMAS
WHERE ASP_NUMBER = 33;Monitorear el estado de la replicacion es esencial para garantizar que el sistema standby esta al dia y listo para un switchover. Los principales indicadores son:
Replication lag
Diferencia de tiempo entre el ultimo cambio en produccion y el ultimo aplicado en el standby. Debe ser de segundos, no minutos.
Journal receiver backlog
Cantidad de journal entries pendientes de enviar o aplicar. Un backlog creciente indica un problema de rendimiento o red.
Objetos no replicados
Objetos nuevos o modificados que no estan incluidos en la configuracion de replicacion. Deben agregarse oportunamente.
Estado del cluster
Verificar que todos los nodos estan activos y el heartbeat funciona. Un nodo caido no sirve como backup.
-- Ver tamano y estado de journal receivers
SELECT JOURNAL_LIBRARY, JOURNAL_NAME,
JOURNAL_RECEIVER_LIBRARY, JOURNAL_RECEIVER_NAME,
ATTACH_TIMESTAMP, SEQUENCE_NUMBER,
JOURNAL_RECEIVER_SIZE
FROM QSYS2.JOURNAL_INFO
WHERE JOURNAL_LIBRARY = 'MILIB';
-- Ver remote journals configurados y su estado
SELECT SOURCE_JOURNAL_LIBRARY, SOURCE_JOURNAL_NAME,
RELATIONAL_DATABASE, DELIVERY_MODE,
TARGET_JOURNAL_LIBRARY, TARGET_JOURNAL_NAME
FROM QSYS2.REMOTE_JOURNAL_INFO
WHERE SOURCE_JOURNAL_LIBRARY = 'MILIB';
-- Ver objetos bajo journaling
SELECT JOURNAL_LIBRARY, JOURNAL_NAME,
OBJECT_LIBRARY, OBJECT_NAME, OBJECT_TYPE,
JOURNALING_START_TIMESTAMP
FROM QSYS2.JOURNAL_OBJECT_INFO
WHERE JOURNAL_LIBRARY = 'MILIB'
ORDER BY OBJECT_NAME;
-- Detectar tablas que NO estan bajo journaling (riesgo para HA)
SELECT TABLE_SCHEMA, TABLE_NAME
FROM QSYS2.SYSTABLES
WHERE TABLE_SCHEMA = 'MILIB'
AND TABLE_TYPE = 'BASE TABLE'
AND TABLE_NAME NOT IN (
SELECT OBJECT_NAME FROM QSYS2.JOURNAL_OBJECT_INFO
WHERE JOURNAL_LIBRARY = 'MILIB'
);Activo-Pasivo (mas comun)
Un servidor de produccion y uno standby. El standby recibe replicacion pero no corre aplicaciones. En caso de switchover, el standby se convierte en el activo.
Ventajas
Simple de administrar, menos riesgo de conflictos, un solo punto de escritura.
Limitaciones
El servidor standby esta subutilizado (solo recibe datos).
Activo-Activo (lecturas)
El servidor standby recibe replicacion y ademas permite lecturas SQL. Se pueden ejecutar reportes y consultas sin impactar produccion.
Ventajas
Mejor uso de recursos, descarga de reportes del servidor de produccion.
Limitaciones
Requiere gestion cuidadosa de que aplicaciones usan cada servidor.
Multisitio (3+ nodos)
Tres o mas nodos en distintas ubicaciones geograficas. Un primario, un backup local y uno o mas remotos para DR.
Ventajas
Proteccion contra desastres regionales, multiples niveles de redundancia.
Limitaciones
Mayor complejidad, costo de lineas de comunicacion, latencia.
Probar el switchover regularmente
Hacer drills de switchover/failover al menos 2 veces al anio. Una HA no probada no es confiable.
Journalear todas las tablas criticas
Verificar periodicamente que no hay tablas sin journaling. Usar IMAGES(*BOTH) para HA.
Monitorear el lag de replicacion
Configurar alertas automaticas si el lag supera un umbral (por ejemplo, 30 segundos).
Documentar el procedimiento
El runbook de switchover/failover debe estar accesible fuera del sistema IBM i (en papel o en otro servidor).
Mantener ambos sistemas actualizados
Aplicar PTFs en ambos nodos. Un standby con version diferente puede fallar durante switchover.
Usar IASPs para datos de aplicacion
Colocar datos en Independent ASPs facilita el switchover y reduce el tiempo de recovery.
Validar datos post-switchover
Despues de cada switch, ejecutar validaciones de integridad de datos para detectar inconsistencias.
Medir RTO real
Cronometrar cada drill de switchover. El RTO medido debe estar dentro del objetivo definido por el negocio.
IBM Db2 Mirror for i (5770-DBM) es una solucion de disponibilidad continua que busca near-zero downtime. Replica datos de forma sincrona entre dos nodos IBM i conectados via RDMA, manteniendo ambas bases de datos identicas en todo momento.
Active/Passive
Un nodo de produccion, el otro en standby con datos live. Ideal para BI en tiempo real en el nodo secundario sin impactar produccion.
Active/Read-Only
El nodo secundario solo puede leer datos replicados. Garantiza integridad impidiendo escrituras accidentales en el standby.
Active/Active
Usuarios y aplicaciones distribuidos en ambos nodos. Cross-node locking garantiza integridad. Verdadero load balancing.
Con Db2 Mirror podes hacer upgrades de release, TRs, PTFs e incluso hardware sin downtime: suspendes replicacion en un nodo, lo actualizas, resincronizas, y repetis con el otro nodo. Esto incluye pasar de IBM i 7.5 a 7.6.
-- Verificar que los PTF groups estan actualizados WITH ILEVEL (IVERSION, IRELEASE) AS ( SELECT OS_VERSION, OS_RELEASE FROM SYSIBMADM.ENV_SYS_INFO ) SELECT P.* FROM ILEVEL, SYSTOOLS.GROUP_PTF_CURRENCY P WHERE PTF_GROUP_RELEASE = 'R' CONCAT IVERSION CONCAT IRELEASE CONCAT '0' ORDER BY PTF_GROUP_LEVEL_AVAILABLE - PTF_GROUP_LEVEL_INSTALLED DESC;
PowerHA SystemMirror ahora soporta replicacion geografica a multiples destinos. Esto permite mantener copias en mas de un sitio remoto simultaneamente, mejorando la proteccion contra desastres regionales.
Permite switchear un conjunto de volumenes (LUNs) de almacenamiento entre dos nodos IBM i dentro del mismo workspace de PowerVS. Se combina tipicamente con Global Replication Services (GRS) para tener HA local dentro del data center y replicacion remota para DR.
Soporte de FlashCopy con iASPs en PowerVS, permitiendo offloadear backups a otro nodo sin impactar produccion. Compatible con Geographic Mirroring y GRS para despliegues all-cloud e hibridos.
GRS es un servicio de replicacion a nivel de almacenamiento en PowerVS que replica datos entre regiones de IBM Cloud. Se combina con PowerHA para lograr una solucion completa de HA+DR en la nube, con replicacion asincrona entre data centers geoespacialmente separados.
IBM i Migrate While Active (MWA) es un LPP disponible desde IBM i 7.4 que reduce el tiempo de migracion a cloud de dias a horas. Usa tecnologia de sincronizacion en tiempo real basada en Db2 Mirror.
Disaster Recovery Automation es una solucion SaaS en IBM Cloud para automatizar operaciones de DR en PowerVS. Soporta IBM i, AIX y Linux.
El pricing se basa en core-hours del sitio de DR, uniforme para todos los tipos de procesador. No incluye cargos de SO, almacenamiento ni networking. Disponible en multiples regiones de PowerVS.