SAP en IBM i: cómo ganar capacidad sin cambiar de plataforma

Por el equipo de Infraestructura de Redsis · Octubre 2026 · 6 min de lectura

Un sector que crece a doble dígito

El retail colombiano atraviesa un ciclo de expansión. Las 20 empresas más grandes del sector sumaron ingresos por $117,3 billones de pesos en 2025, un 12,3 % más que el año anterior, y las cinco primeras concentraron el 65,2 % de esos ingresos, según el ranking publicado por El Colombiano. Nuestro cliente es una de esas cinco.

Para los equipos de tecnología, ese crecimiento se traduce en más referencias, más tiendas, más transacciones y más historia acumulada en la base de datos. Y en un ERP con años de operación, la curva de consumo de memoria y almacenamiento rara vez es plana.

El doble techo: cómputo y almacenamiento al mismo tiempo

La situación de la cadena era un caso típico, pero exigente. El análisis del comportamiento de SAP mostraba que el servidor IBM Power E870 necesitaría más procesamiento y memoria para sostener la operación productiva durante aproximadamente un año más. Al mismo tiempo, toda la capacidad de almacenamiento del ambiente productivo ya estaba asignada en dos sistemas IBM Storwize V7000 virtualizados detrás de un IBM SAN Volume Controller.

Cuando los dos límites llegan juntos aparece la tentación de resolverlo todo con un proyecto grande: servidor nuevo, almacenamiento nuevo, migración completa. A veces es la respuesta correcta. Pero en este caso había una alternativa más eficiente.

Capacidad bajo demanda: pagar por lo que el negocio necesita, cuando lo necesita

Los servidores IBM Power de gama empresarial se entregan con procesadores y memoria que pueden estar instalados pero inactivos. Con el modelo Capacity on Demand , esa capacidad se activa mediante licenciamiento, de forma permanente o por un período definido, sin cambiar de equipo ni detener el sistema.

Para la cadena, Redsis habilitó en su Power E870 el equivalente a 20 cores POWER8 y 512 GB de memoria bajo demanda por un período definido. Los 512 GB se sumaron a los 1,5 TB existentes para llegar a 2 TB de RAM, suficientes para acompañar el horizonte de operación que mostraba el análisis de la aplicación. La cadena puede usar esa capacidad según los requerimientos del negocio, sin cambiar de plataforma.

Almacenamiento: renovar sin cambiar la arquitectura

En almacenamiento la decisión fue mantener lo que funcionaba —una arquitectura virtualizada con réplica local— y renovar los componentes con tecnología flash de última generación:

• IBM SAN Volume Controller 2147-SV2. SVC virtualiza el almacenamiento y presenta a los servidores un pool único de capacidad, independiente del arreglo físico que hay detrás. El nuevo modelo aporta más procesamiento y más memoria caché, e incluye un equipo de respaldo.
• Dos IBM FlashSystem 7200 para producción. Cada uno con 107 TB de capacidad efectiva, reemplazan a los Storwize V7000 y distribuyen las cargas del ambiente SAP.
• Un tercer FlashSystem 7200 para la copia local. Otros 107 TB efectivos para mantener una réplica del ambiente en un sistema alterno, mediante Volume Mirror del SVC.
• FlashCopy con Thin Provisioning. La cadena conserva su esquema de copias de respaldo basado en instantáneas del almacenamiento, con volúmenes que solo consumen el espacio realmente escrito.
• Dos switches SAN nuevos para la conectividad entre servidor y almacenamiento.

El resultado es un total de 321 TB efectivos en flash y una arquitectura que el equipo del cliente ya conocía, lo que reduce la curva de aprendizaje y el riesgo operativo del cambio.

Cinco lecciones para dimensionar SAP sobre IBM i

1. Dimensionar con datos de la aplicación, no con intuición

El punto de partida fue el comportamiento real de SAP en producción. Proyectar consumo de CPU y memoria a partir de la operación actual permite comprar la capacidad para un horizonte concreto, en lugar de sobredimensionar "por si acaso".

2. Separar la decisión de cómputo de la de almacenamiento

El servidor y el almacenamiento no siempre envejecen al mismo ritmo. Tratar cada frente con la herramienta adecuada —capacidad bajo demanda en uno, renovación en el otro— suele ser más eficiente que un reemplazo total.

3. Aprovechar la virtualización del almacenamiento

Con una capa como SVC, cambiar los arreglos de disco que hay detrás es mucho menos disruptivo: los servidores siguen viendo los mismos volúmenes mientras los datos se mueven al nuevo hardware.

4. Incluir la copia local desde el diseño

La réplica en un sistema alterno no es un complemento para después. Diseñarla junto con la capacidad productiva asegura que ambas crezcan al mismo ritmo.

5. Llevar la conversación al costo total de propiedad

Fue la clave de este proyecto. Redsis presentó un análisis de costo total de propiedad con el que la cadena pudo ver que el cambio de sus sistemas de almacenamiento le daba mejor desempeño y mayor capacidad a un menor costo total. Soporte de equipos antiguos, consumo de energía, espacio en el centro de datos y esfuerzo de administración pesan tanto como el precio de compra.

El resultado: más capacidad, menos costo total

Hoy el SAP Retail de la cadena cuenta con 2 TB de RAM, 20 cores POWER8 adicionales disponibles bajo demanda y 321 TB efectivos en IBM FlashSystem 7200, con réplica local de todo el ambiente y su esquema de respaldo intacto. Todo sobre la misma plataforma IBM Power e IBM i que ya soportaba su operación nacional, con más desempeño y a un menor costo total de propiedad.

¿Por dónde empezar?

Si su ambiente SAP sobre IBM i muestra señales de saturación —memoria al límite, almacenamiento asignado al 100 % o equipos que salen de soporte—, el primer paso es un diagnóstico de capacidad basado en datos reales. En Redsis combinamos más de 25 años de experiencia en infraestructura de misión crítica en América Latina con nuestra condición de socio IBM Platinum para diseñar la combinación correcta de cómputo, almacenamiento y costo.