Optimització del Grid Computing HPC
Una gran entitat bancària espanyola amb infraestructura HPC fragmentada necessitava reduir els temps de càlcul financer crític i millorar la utilització de recursos al seu grid corporatiu.
Repte
Grid HPC fragmentat amb baixa utilització de recursos. Els processos de càlcul financer crític consumien finestres de temps insostenibles, bloquejant les operacions del negoci.
Solució
Unificació del grid corporatiu, optimització de polítiques de planificació, automatització de processos crítics i reducció de temps de càlcul amb anàlisi tècnica profunda.
Tecnologies
- HPC / Grid Computing
- Optimització de càrregues de treball
- Arquitectura híbrida
- Automatització de processos
Contexto
La Sala de Tesorería de un gran grupo financiero español ejecuta cálculos de riesgo cada vez más complejos y frecuentes, en respuesta a exigencias regulatorias como las de Basilea o las del Banco de España. Esos cálculos corren sobre un sistema GRID corporativo que reparte las tareas entre miles de núcleos on-premise.
El problema no era la falta de tecnología, sino una infraestructura que no escalaba bajo presión: los picos diarios saturaban la capacidad disponible y, fuera de ellos, la plataforma quedaba sobredimensionada. La organización necesitaba una solución flexible, escalable y compatible con el GRID ya implantado, sin sustituirlo.
El reto
Cuatro fricciones concentraban el coste, el plazo y el riesgo regulatorio:
- Sobrecarga en momentos críticos: los picos de cálculo diario, especialmente desde Tesorería, saturaban la infraestructura disponible.
- Escalado lento y costoso: ampliar hardware no era una solución viable a corto plazo ni eficiente a largo.
- Baja eficiencia operativa: en periodos de baja carga la infraestructura estaba sobredimensionada, con un coste poco optimizado.
- Dependencia del entorno local: la arquitectura GRID existente limitaba la adopción de soluciones más flexibles sin una integración adecuada.
Enfoque por fases
El proyecto se ejecutó en cinco fases, asegurando una adopción progresiva, controlada y alineada con los requisitos operativos del banco.
-
01
PoC y arquitectura híbrida
Validación técnica inicial y diseño de una arquitectura compatible con el GRID existente y con la nube.
-
02
Definición del autoescalado
Establecimiento de las métricas de carga que activan nodos según la demanda real de los gestores de cálculo.
-
03
Integración y testing
Validación del funcionamiento de los nodos cloud como parte transparente del clúster de cómputo.
-
04
Automatización y monitorización
Orquestación completa del ciclo de vida de los nodos y supervisión continua con alertas preventivas.
-
05
Cargas reales y ajustes
Ejecución de cargas productivas y ajuste fino de las políticas de escalado.
Arquitectura y estrategia
La clave fue extender, no reemplazar. Se configuraron grupos de autoescalado (Auto Scaling Groups) que crean y destruyen nodos cloud automáticamente en función de la carga detectada por los gestores de cálculo. Esos nodos se integran en el clúster de cómputo del banco, de modo que los procesos de riesgo y tesorería los utilizan como si fueran parte del entorno on-premise.
El flujo es simple: las tareas de cálculo se gestionan desde el sistema central GRID; primero se usan los núcleos fijos internos, que funcionan siempre; si resultan insuficientes, se activan automáticamente núcleos adicionales en la nube; cuando las tareas terminan, esos nodos se apagan solos. Compatibilidad total con la infraestructura existente, escalabilidad adaptada a la carga real, automatización del ciclo de vida de los recursos cloud y monitorización continua con capacidad de reacción inmediata.
Resultados medibles
La arquitectura híbrida transformó un cuello de botella operativo en una ventaja competitiva: no solo resolvió el problema de carga, sino que mejoró el rendimiento de los sistemas de riesgo y tesorería.
| Indicador | Antes | Después |
|---|---|---|
| Tiempo total de ejecución de las cargas de riesgo | Ventanas saturadas en picos | −35 % |
| Capacidad de cómputo | Limitada al hardware on-premise | +200 % sin inversión física |
| Coste operativo mensual de cómputo | Sobredimensionamiento permanente | −20 % de media (pay-per-use) |
| Escalabilidad validada | Ampliación manual de hardware | +1.500 núcleos simultáneos |
Cifras agregadas y anonimizadas por acuerdo de confidencialidad. Fuente: proyectos de Vermont Solutions.
Lecciones aplicables
- Extender antes que reemplazar: se obtienen las ventajas del cloud sin disrupción ni riesgo para la operativa de Tesorería.
- Autoescalar por demanda elimina el sobredimensionamiento y convierte el coste fijo en variable.
- La integración transparente en el clúster evita cambiar los procesos de negocio: para el gestor de cálculo, un nodo cloud es un nodo más.
- La monitorización continua con alertas preventivas es lo que permite confiar en el escalado automático en un entorno regulado.
Marco regulatorio
El cálculo de riesgo de una entidad bancaria está sujeto a plazos y a exigencias del supervisor; la capacidad de cómputo es, por tanto, un requisito de cumplimiento y no solo de eficiencia.
- Basilea III/IV y los requerimientos del Banco de España: cálculos de capital y riesgo más frecuentes y exigentes.
- DORA (Art. 28): la extensión a la nube se diseña como riesgo de tercero tecnológico, con control del proveedor y resiliencia operativa digital.
- NIS2: seguridad de redes y sistemas en un sector esencial; enrutamiento seguro entre el CPD y la nube (balanceadores, VPN, reglas de failover).
Preguntas frecuentes
¿Hubo que modificar los procesos de riesgo o tesorería para usar la nube?
No. Los nodos cloud se integran en el clúster GRID existente y los gestores de cálculo los tratan como núcleos propios. Los procesos de negocio no cambian; cambia la capacidad disponible detrás.
¿Qué ocurre con el coste cuando no hay picos de carga?
Los nodos cloud se apagan solos al terminar las tareas. El modelo pay-per-use elimina el sobredimensionamiento: el coste operativo mensual de cómputo bajó un 20 % de media.
¿Es aplicable a un GRID sobre IBM Spectrum Symphony o TIBCO DataSynapse?
Sí. El diseño es independiente del gestor de cálculo: la extensión se hace a nivel de nodos del clúster. Vermont mantiene equipo especializado en ambos productos y en su migración.
¿Puedo conocer la entidad y las cifras completas?
El caso está anonimizado por acuerdo de confidencialidad. El detalle de arquitectura y las cifras completas se comparten previa firma de NDA.
Contenido relacionado
Última actualización: 2026-09-12