Arquitectura SAP Business One sobre HANA en SUSE Linux: Rendimiento y Alta Disponibilidad

El Cambio de Paradigma: SAP HANA In-Memory Computing#

La evolución de SAP Business One hacia la versión for SAP HANA representa una reestructuración completa del motor de base de datos. Al abandonar los RDBMS tradicionales basados en disco (como SQL Server) en favor de una arquitectura in-memory basada en columnas, las empresas pueden procesar analíticas en tiempo real simultáneamente con el procesamiento transaccional (OLTP y OLAP convergentes).

Para que este motor alcance su máximo potencial, la infraestructura subyacente requiere una plataforma hiper-optimizada. Es aquí donde SUSE Linux Enterprise Server (SLES) for SAP Applications se convierte en el estándar de facto.

Nota de Arquitectura: El despliegue de SAP HANA exige una configuración de hardware certificada (TDI - Tailored Datacenter Integration) o appliances preconfigurados para garantizar los ratios requeridos de CPU-memoria (típicamente 1.5 a 2 TB de RAM por socket en entornos B1).

Componentes Críticos del Stack sobre SLES#

La pila de ejecución de SAP B1 sobre HANA en SUSE involucra varios servicios desacoplados que deben ser gestionados a nivel del sistema operativo.

1. SLES Kernel Tuning (saptune)

SUSE incorpora la utilidad saptune, una herramienta indispensable para aplicar automáticamente las notas de SAP recomendadas al kernel de Linux, optimizando la gestión de memoria, parámetros de red y planificadores de I/O.

# Verificar los perfiles de saptune disponibles
saptune solution list

# Aplicar el perfil específico para HANA
saptune solution apply HANA

# Verificar el estado de la aplicación de notas (e.g., SAP Note 1980122)
saptune verify HANA

2. File System y Gestión de Volúmenes (LVM & XFS)

HANA requiere volúmenes de disco separados para data y log. Aunque el procesamiento es en memoria, HANA guarda el estado para persistencia. SLES recomienda XFS como sistema de archivos debido a su eficiencia en la escritura de grandes bloques de datos y snapshots.

# Arquitectura recomendada de montaje en fstab:
/dev/mapper/vg_hana-lv_hana_data /hana/data xfs nobarrier,inode64 1 2
/dev/mapper/vg_hana-lv_hana_log  /hana/log  xfs nobarrier,inode64 1 2
/dev/mapper/vg_hana-lv_hana_shared /hana/shared xfs inode64 1 2

Patrones de Alta Disponibilidad (High Availability - HA)#

Para entornos de misión crítica, se debe configurar SAP HANA System Replication (HSR) integrado con el cluster Pacemaker de SUSE (Corosync). Esto permite un failover automatizado de la base de datos sin intervención manual.

Arquitectura Active/Passive con HSR

En este esquema, el Nodo 1 (Primario) replica transaccionalmente los logs hacia el Nodo 2 (Secundario) de forma síncrona (SYNC o SYNCMEM).

Advertencia de Split-Brain: Es imperativo configurar mecanismos de STONITH (Shoot The Other Node In The Head), como dispositivos SBD (Storage-Based Death) o agentes de fencing IPMI, para evitar la corrupción de datos en caso de pérdida de red de interconexión.

# Registro del nodo secundario en la replicación HANA
su - <sid>adm
hdbnsutil -sr_register --name=SITE_B --remoteHost=nodo-primario --remoteInstance=00 --replicationMode=sync --operationMode=logreplay

# Integración con el cluster Pacemaker en SLES
crm configure show

SAP Business One Server Components

Encima de la infraestructura HANA, se instalan los componentes de la capa de aplicación de SAP B1:

• System Landscape Directory (SLD): El corazón de la topología B1.
• Service Layer: La nueva API basada en OData para integraciones modernas.
• Analytics Platform: El motor de modelos semánticos de HANA.

La capa de aplicación (B1 Server Tools y Server) interactúa con HANA exclusivamente a través del cliente hdbclient. La optimización del parámetro tcp_keepalive en SLES previene la desconexión de sesiones largas de B1 hacia la base de datos, garantizando estabilidad en transacciones pesadas como el cálculo de MRP.