Importancia del dimensionamiento correcto
El dimensionamiento es el proceso de calcular los recursos de hardware necesarios para que un sistema SAP funcione con rendimiento aceptable. Un dimensionamiento incorrecto lleva a sistemas lentos que frustran usuarios y afectan la productividad, o a hardware sobredimensionado que desperdicia recursos económicos.
En la arquitectura SAP, el dimensionamiento afecta cada capa del sistema: servidores de aplicación, base de datos, almacenamiento y red. Cada componente debe dimensionarse adecuadamente para evitar cuellos de botella que degraden el rendimiento global.
Factores que afectan el dimensionamiento
El número de usuarios concurrentes es el factor más obvio pero no el único. SAP distingue entre usuarios named (licencias asignadas a personas específicas) y usuarios concurrentes (personas realmente conectadas simultáneamente). Típicamente solo el 30-40% de usuarios named están activos simultáneamente.
El perfil de uso importa más que el número bruto de usuarios. Usuarios de diálogo que ejecutan transacciones constantemente consumen muchos más recursos que usuarios ocasionales que consultan informes esporádicamente. SAP clasifica usuarios en categorías según su intensidad de uso.
El volumen de datos determina los requisitos de base de datos y memoria. Un sistema con millones de documentos y años de historial necesita significativamente más recursos que uno pequeño. El crecimiento de datos debe proyectarse para dimensionar considerando el futuro, no solo el presente.
Los procesos batch afectan el dimensionamiento porque ejecutan en horarios específicos. El cierre contable de fin de mes puede generar picos de carga mucho mayores que la operación diaria. El sistema debe dimensionarse para manejar estos picos, no solo la carga promedio.
La complejidad del customizing y desarrollos custom impacta el rendimiento. Código ABAP ineficiente, configuraciones complejas con múltiples derivaciones y validaciones, y procesos de negocio pesados aumentan los recursos necesarios.
SAPS: unidad de medida SAP
SAP define el SAPS (SAP Application Performance Standard) como unidad de medida de rendimiento. Un SAPS equivale a 100 líneas de documento SD (Sales & Distribution) procesadas completamente por hora, incluyendo actualización de base de datos.
Esta métrica benchmark permite comparar el rendimiento de diferentes configuraciones de hardware de forma estandarizada. Los fabricantes de hardware certifican sus servidores indicando cuántos SAPS pueden proporcionar.
Un sistema empresarial típico puede requerir entre 5,000 y 50,000 SAPS dependiendo del tamaño y complejidad. Los sistemas muy grandes pueden necesitar 100,000 SAPS o más. El cálculo exacto considera usuarios, transacciones, módulos implementados y volumen de batch.
SAP Quick Sizer
SAP Quick Sizer es la herramienta oficial de SAP para dimensionamiento inicial de sistemas. Solicita información sobre el número de usuarios por módulo, volúmenes de transacciones, tamaño de base de datos esperado y patrones de uso.
Quick Sizer genera recomendaciones de CPU, memoria RAM, espacio en disco y SAPS necesarios. Proporciona estimaciones separadas para servidores de aplicación y base de datos, considerando la arquitectura de tres capas.
Las estimaciones son punto de partida, no verdades absolutas. Deben refinarse con conocimiento del negocio específico, particularidades de la implementación y mediciones reales una vez el sistema esté operativo.
Quick Sizer está disponible gratuitamente en el SAP Service Marketplace para cualquiera con una S-User. Es útil tanto para nuevas implementaciones como para proyectos de upgrade o migración a S/4HANA.
Dimensionamiento de servidores de aplicación
Los servidores de aplicación necesitan principalmente potencia de CPU para ejecutar la lógica ABAP. La cantidad de RAM determina cuántos work processes pueden ejecutarse simultáneamente y qué tan efectivos son los buffers de memoria.
Una regla aproximada es 2 GB de RAM por cada 10 work processes, más overhead del sistema operativo y la instancia SAP. Un servidor con 64 GB puede alojar cómodamente 200-250 work processes distribuidos entre diálogo, background, update y spool.
El número de work processes por servidor debe balancearse cuidadosamente. Demasiados work processes saturan la CPU y degradan el rendimiento de todos. Muy pocos work processes provocan colas de espera incluso con CPU disponible.
Las configuraciones típicas asignan 3-5 work processes de diálogo por core de CPU. Un servidor con 16 cores puede tener 50-80 work processes de diálogo, más additional work processes de background, update y spool según la carga de trabajo esperada.
Dimensionamiento de base de datos
La base de datos requiere suficiente RAM para mantener en memoria los datos más accedidos (working set). Para bases de datos tradicionales como Oracle o SQL Server, típicamente se dimensiona RAM equivalente al 30-50% del tamaño de la base de datos.
Los servidores de base de datos necesitan menos CPU que los de aplicación pero más memoria. Un ratio común es dimensionar la base de datos con 50-60% de la potencia SAPS total, dejando el resto para servidores de aplicación.
El dimensionamiento de SAP HANA es fundamentalmente diferente porque mantiene todos los datos en memoria. La RAM necesaria debe ser al menos 1.5-2 veces el tamaño estimado de los datos en memoria (considerando compresión y overhead operativo).
Para ECC con base de datos tradicional de 1 TB, un servidor con 512 GB RAM puede ser adecuado. Para S/4HANA con 300 GB de datos comprimidos en HANA, se necesitarían 600-800 GB de RAM mínimo.
Escalabilidad vertical vs horizontal
Escalabilidad vertical significa añadir más recursos (CPU, RAM) a servidores existentes. Es simple de implementar pero tiene límites técnicos. Los servidores físicos tienen slots máximos de RAM y sockets de CPU. Eventualmente no se puede crecer más sin reemplazar el hardware.
Escalabilidad horizontal significa añadir más servidores al sistema. En la capa de aplicación SAP es casi ilimitada. Se pueden añadir servidores de aplicación adicionales al landscape y el message server distribuirá automáticamente la carga entre ellos.
La escalabilidad horizontal requiere balanceo de carga adecuado. Los grupos de logon distribuyen usuarios entre servidores disponibles. El dimensionamiento debe garantizar que cada servidor individual puede manejar su porción de la carga total.
La base de datos escala horizontalmente con más dificultad. Tecnologías como Oracle RAC permiten múltiples instancias accediendo a los mismos datos, pero añaden complejidad significativa. HANA scale-out distribuye datos entre múltiples nodos, pero no todas las operaciones escalan linealmente.
Dimensionamiento de almacenamiento
El almacenamiento debe calcularse considerando el tamaño actual de base de datos, crecimiento proyectado, logs de base de datos, backups locales si se almacenan en el servidor, y filesystems del sistema SAP.
Una regla general para sistemas productivos es provisionar 3-4 veces el tamaño de la base de datos: 1x para los datos actuales, 1x para crecimiento, 1x para logs y temporales, 1x para backups locales si aplica.
El rendimiento del almacenamiento es tan crítico como la capacidad. Los subsistemas de base de datos requieren IOPS (operaciones de entrada/salida por segundo) elevados. Los discos SSD o almacenamiento all-flash son prácticamente obligatorios para sistemas grandes en producción.
SAP HANA tiene requisitos específicos de almacenamiento según el tamaño del sistema. SAP proporciona calculadoras específicas que determinan el almacenamiento necesario considerando datos, logs, backups y área de persistencia.
Monitorización y ajuste continuo
El dimensionamiento inicial es solo el punto de partida. Los sistemas deben monitorizarse continuamente para identificar cuellos de botella y ajustar recursos según sea necesario.
Las transacciones ST06 (sistema operativo) y ST03 (estadísticas de workload) proporcionan métricas detalladas de utilización de CPU, memoria, base de datos y tiempos de respuesta. Los administradores BASIS deben revisar estas estadísticas regularmente.
Los tiempos de respuesta son el indicador clave de rendimiento desde la perspectiva del usuario. SAP recomienda que el tiempo promedio de respuesta de transacciones de diálogo sea inferior a 1 segundo. Tiempos consistentemente superiores indican subdimensionamiento o problemas de rendimiento.
La utilización de CPU debe mantenerse por debajo del 70-80% en promedio para dejar margen para picos. Una CPU constantemente al 100% indica necesidad de añadir servidores o optimizar código ineficiente.
Dimensionamiento de entornos no productivos
Los sistemas de desarrollo (DEV) y calidad (QAS) no requieren el mismo dimensionamiento que producción (PRD). El número de usuarios concurrentes es menor y no hay presión de rendimiento crítico del negocio.
Una práctica común es dimensionar QAS al 70-80% de la capacidad de PRD. Debe ser suficientemente potente para ejecutar pruebas de rendimiento realistas, pero no necesita manejar la carga completa de producción.
DEV puede ser aún más pequeño, dimensionado para el equipo de desarrollo y consultores que trabajan en él. Sin embargo, si DEV es demasiado pequeño, los problemas de rendimiento pueden no detectarse hasta QAS o incluso producción.
Las estrategias cloud pueden optimizar costes ejecutando sistemas no productivos en instancias que se apagan fuera del horario laboral, reduciendo gastos significativamente sin afectar la funcionalidad.
Migración a S/4HANA
La migración de ECC a S/4HANA requiere redimensionamiento completo. HANA necesita mucha más RAM que bases de datos tradicionales, pero los datos ocupan menos espacio gracias a la compresión.
Como estimación, los datos en HANA ocupan aproximadamente 25-30% del tamaño que tenían en la base de datos tradicional de ECC. Un sistema ECC con 1 TB en Oracle puede reducirse a 250-300 GB en HANA.
Sin embargo, la RAM necesaria debe ser 1.5-2x el tamaño de datos comprimidos, más overhead. Ese sistema de 300 GB en HANA necesitaría 600-800 GB de RAM, mucho más que los 512 GB que podría tener el servidor de Oracle.
SAP proporciona herramientas específicas como HANA Sizing Report que analizan el sistema ECC actual y estiman los recursos necesarios para S/4HANA, considerando patrones de uso reales.
Consideraciones de virtualización
La virtualización añade una capa de abstracción entre SAP y el hardware físico. Los hipervisores consumen recursos (CPU overhead del 5-15%) que deben considerarse en el dimensionamiento.
SAP certifica configuraciones específicas de VMware, Hyper-V y otros hipervisores. Los sistemas productivos críticos requieren que la virtualización esté certificada y configurada según las guías SAP.
La virtualización proporciona flexibilidad para ajustar recursos dinámicamente sin cambiar hardware físico. Una VM que necesita más RAM puede expandirse sin migrar a otro servidor, aunque esto requiere planificación de capacidad del host físico.
Dimensionamiento en cloud
Los proveedores cloud (AWS, Azure, Google Cloud) ofrecen tipos de instancias certificadas por SAP que simplifican el dimensionamiento. En lugar de calcular SAPS, se selecciona el tipo de instancia que cumple los requisitos.
La elasticidad cloud permite escalar verticalmente (cambiar a instancias más grandes) u horizontalmente (añadir instancias) según demanda. Esta flexibilidad es valiosa para manejar picos estacionales sin sobredimensionar permanentemente.
Los costes cloud son por uso, lo que significa que subdimensionar tiene penalización de rendimiento pero sobredimensionar tiene impacto económico directo. El balance óptimo requiere monitorización continua y ajustes.
Para más detalles sobre consideraciones de despliegue, consulta arquitectura on-premise vs cloud.
Preguntas Frecuentes (FAQ)
¿Qué es un SAPS?
SAPS (SAP Application Performance Standard) es una unidad de medida de rendimiento. 100 SAPS equivalen a procesar 100 líneas de documento SD por hora bajo un benchmark estandarizado de SAP.
¿Para qué sirve el SAP Quick Sizer?
Es la herramienta oficial de SAP para estimar los requisitos de hardware (CPU, RAM, Disco) basándose en el número de usuarios, volumen de transacciones y módulos implementados.
¿Cuál es la diferencia entre escalabilidad vertical y horizontal en SAP?
La escalabilidad vertical implica aumentar los recursos (CPU/RAM) de un servidor existente. La horizontal implica añadir nuevos servidores de aplicación al sistema para distribuir la carga.
Temas relacionados
Para profundizar en dimensionamiento y escalabilidad, consulta:
Conceptos básicos para entender work processes y arquitectura de memoria que afectan el dimensionamiento.
Capas del sistema para dimensionar cada capa independientemente.
Alta disponibilidad para considerar recursos adicionales necesarios en configuraciones HA.
SAP HANA para dimensionamiento específico de la base de datos in-memory.
SAP BASIS para tareas de monitorización y ajuste de rendimiento.