OPE 2025. TFA INF. Tema 51. Arquitecturas básicas de los sistemas informáticos. La planificación de los sistemas informáticos. Capacidad, rendimiento, flexibilidad, escalabilidad y alta disponibilidad. Conceptos y funcionalidades básicas de las unidades centrales multiusuario. Evolución y tendencia de las unidades centrales multiusuario. Sistemas departamentales y grandes sistemas centrales.

Servicio Andaluz de Salud EXAMEN INFORMÁTICA JUNTA DE ANDALUCÍA Exámenes SAS 2025 TFA INF (P) TFA INFORMÁTICA
Esteban CastroDeja un comentario en OPE 2025. TFA INF. Tema 51. Arquitecturas básicas de los sistemas informáticos. La planificación de los sistemas informáticos. Capacidad, rendimiento, flexibilidad, escalabilidad y alta disponibilidad. Conceptos y funcionalidades básicas de las unidades centrales multiusuario. Evolución y tendencia de las unidades centrales multiusuario. Sistemas departamentales y grandes sistemas centrales.
Tema 51 – Arquitecturas y Planificación de Sistemas – TFA-STI SAS
TEMA 51

ARQUITECTURAS Y PLANIFICACIÓN
DE SISTEMAS INFORMÁTICOS
ESCALABILIDAD · ALTA DISPONIBILIDAD · SISTEMAS MULTIUSUARIO

Técnico/a de Función Administrativa – Opción Sistemas y Tecnología de la Información (TFA-STI)
Servicio Andaluz de Salud

1. CONTEXTUALIZACIÓN Y RELEVANCIA PARA TFA-STI SAS

🏗️ Del Fundamento a la Arquitectura Empresarial

Si el Tema 50 te explicó cómo funciona un ordenador (bits, puertas lógicas, Von Neumann), este tema te explica cómo se diseñan, planifican y gestionan sistemas informáticos completos que dan servicio a miles de usuarios simultáneos.

No hablaremos de un PC individual. Hablaremos de los sistemas que mantienen vivo al SAS: Diraya atendiendo a miles de profesionales sanitarios a la vez, ClicSalud+ con millones de consultas diarias, servidores de receta electrónica que NO PUEDEN CAER.

💡 Por qué este tema es CRÍTICO para el SAS

  • 🏥 Diraya: Sistema de historia clínica digital multiusuario con requisitos de alta disponibilidad
  • 📱 ClicSalud+: Portal con picos de demanda (mañanas, octubre) que requiere escalabilidad
  • 💊 Receta electrónica: Sistema crítico 24/7, tolerancia CERO a caídas (99.99% uptime)
  • 🔧 Como TFA-STI: Participarás en planificación de capacidad, dimensionamiento, actualizaciones sin interrupción
  • 📊 Decisiones técnicas: ¿Escalado vertical u horizontal? ¿On-premise o cloud? ¿Active-active o active-passive?

⚠️ La Importancia de Planificar

Un sistema mal dimensionado tiene consecuencias REALES en el SAS:

  • ❌ Subdimensionado: Diraya lento → médicos no pueden trabajar → pacientes sin atender
  • ❌ Sobredimensionado: Desperdicio presupuestario → menos inversión en otros servicios
  • ❌ Sin redundancia: Caída de servidor → Centros de salud sin receta electrónica
  • ❌ Sin escalabilidad: Imposible crecer → Colapso en picos de demanda

Planificar correctamente NO es opcional. Es una responsabilidad.

2. ARQUITECTURAS BÁSICAS DE SISTEMAS INFORMÁTICOS

2.1. Evolución de Arquitecturas

Evolución Histórica de Arquitecturas
AÑOS 60-70: MAINFRAME CENTRALIZADO
┌─────────────────────────────────────┐
│         MAINFRAME IBM               │
│  (Toda la lógica y datos)           │
│                                     │
│  ┌──────────────────────────────┐  │
│  │  Aplicaciones                │  │
│  │  Datos                       │  │
│  │  Procesamiento               │  │
│  └──────────────────────────────┘  │
└────────┬────────────────────────────┘
         │
    ┌────┴────┐
    │ Termina-│  Terminales tontos
    │  les    │  (solo E/S)
    └─────────┘

AÑOS 80-90: CLIENTE/SERVIDOR
┌──────────────┐         ┌──────────────┐
│   CLIENTE    │         │   SERVIDOR   │
│              │         │              │
│ • Presenta-  │◀───────▶│ • Lógica     │
│   ción       │  Red    │   negocio    │
│ • Lógica     │ LAN/WAN │ • Datos      │
│   parcial    │         │              │
└──────────────┘         └──────────────┘
(PC con Windows/Office)  (Unix/DB Server)

AÑOS 2000-ACTUALIDAD: ARQUITECTURA N-CAPAS
┌──────────┐  HTTP/S  ┌──────────┐  API  ┌──────────┐
│ CLIENTE  │◀────────▶│   WEB    │◀─────▶│   APP    │
│ (Browser)│          │  SERVER  │       │  SERVER  │
│  Móvil   │          │ (Apache, │       │ (Logic)  │
│  PWA     │          │  Nginx)  │       │          │
└──────────┘          └──────────┘       └────┬─────┘
                                              │
                                         ┌────▼─────┐
                                         │   DATA   │
                                         │  SERVER  │
                                         │ (Oracle, │
                                         │Postgres) │
                                         └──────────┘

HOY Y FUTURO: MICROSERVICIOS + CLOUD
┌────────────────────────────────────────────────┐
│              API GATEWAY                       │
└────┬───────┬────────┬────────┬────────┬───────┘
     │       │        │        │        │
┌────▼──┐ ┌──▼───┐ ┌─▼────┐ ┌─▼────┐ ┌▼─────┐
│User   │ │Citas │ │Receta│ │Histor│ │Notif.│
│Service│ │Service│ │Servic│ │Service│ │Servic│
└───┬───┘ └──┬───┘ └──┬───┘ └──┬───┘ └──┬───┘
    │        │        │        │        │
    └────────┴────────┴────────┴────────┘
                     │
            ┌────────▼─────────┐
            │   CLOUD (Azure)  │
            │  • Contenedores  │
            │  • Auto-scaling  │
            │  • Load Balancer │
            └──────────────────┘

2.2. Arquitectura Cliente-Servidor

La arquitectura cliente-servidor es el modelo fundamental que aún domina la mayoría de sistemas empresariales.

Aspecto Cliente Servidor
Función Solicita servicios Proporciona servicios
Iniciativa Inicia comunicación (activo) Espera peticiones (pasivo)
Cantidad Muchos clientes Pocos servidores (más potentes)
Recursos Limitados (PC, móvil) Abundantes (CPU, RAM, discos)
Ejemplo SAS Puesto médico con Diraya Servidor aplicaciones Diraya

2.2.1. Tipos de Cliente-Servidor

🖥️ Cliente Pesado (Thick/Fat Client)

  • Definición: Mucha lógica en cliente
  • Ventaja: Mejor rendimiento, experiencia rica
  • Desventaja: Compleja distribución/actualización
  • Ejemplo: Aplicación .NET instalada localmente

🌐 Cliente Ligero (Thin Client)

  • Definición: Lógica mínima, solo presentación
  • Ventaja: Fácil mantenimiento, multiplataforma
  • Desventaja: Dependiente de red, UX limitada
  • Ejemplo: Navegador web (ClicSalud+)

2.3. Arquitectura en Capas (N-Tier)

Separa el sistema en capas lógicas independientes, cada una con responsabilidad específica.

📚 Arquitectura 3 Capas (Estándar)

  1. Capa de Presentación: Interfaz usuario (HTML/CSS/JS, apps móviles)
  2. Capa de Lógica de Negocio: Reglas, validaciones, workflows (Java, .NET, Python)
  3. Capa de Datos: Persistencia (RDBMS, NoSQL)

Ventaja: Separación de responsabilidades, mantenibilidad, escalabilidad independiente por capa

2.4. Arquitectura de Microservicios

Evolución de N-capas: en lugar de un monolito, múltiples servicios pequeños, independientes y desplegables por separado.

🔬 Características de Microservicios

  • ✅ Autonomía: Cada servicio es independiente
  • ✅ Descentralización: Sin punto único de fallo
  • ✅ Poliglota: Cada servicio puede usar stack tecnológico diferente
  • ✅ Escalado granular: Escalar solo servicios con más carga
  • ✅ Despliegue independiente: Actualizar un servicio sin afectar otros
  • ❌ Complejidad: Orquestación, trazabilidad distribuida, consistencia eventual
Ejemplo: Microservicios en ClicSalud+ (hipotético)
┌─────────────── API GATEWAY (Kong) ────────────────┐
│  • Autenticación                                   │
│  • Rate Limiting                                   │
│  • Routing                                         │
└────────────────────┬───────────────────────────────┘
                     │
     ┌───────────────┼───────────────┐
     │               │               │
┌────▼────────┐ ┌───▼───────┐ ┌────▼────────┐
│ User Service│ │Cita Service│ │ Receta Serv.│
│             │ │           │ │             │
│ • Login     │ │• Solicitar│ │ • Consultar │
│ • Perfil    │ │• Modificar│ │ • Validar   │
│ • Auth      │ │• Anular   │ │ • Dispensar │
│             │ │           │ │             │
│ MongoDB     │ │PostgreSQL │ │ Oracle      │
└─────────────┘ └───────────┘ └─────────────┘
                     │
            ┌────────▼─────────┐
            │ Message Bus      │
            │ (Kafka/RabbitMQ) │
            └──────────────────┘
            
Cada servicio:
• Tiene su propia base de datos
• Se despliega independientemente
• Puede escalar según demanda
• Falla sin afectar a otros (si está bien diseñado)

2.5. Arquitectura Distribuida y Cloud

Sistemas cuyos componentes residen en múltiples localizaciones geográficas, coordinados mediante red.

Modelo Características Uso SAS
On-Premise Servidores propios en CPD SAS Diraya (datos sensibles, control total)
IaaS (Infrastructure) VMs, almacenamiento, redes en cloud Servidores desarrollo/testing en Azure
PaaS (Platform) Plataforma gestionada (BD, middleware) Azure SQL Database, App Services
SaaS (Software) Aplicación completa en cloud Microsoft 365, Zoom, Salesforce
Híbrido Combinación on-premise + cloud Diraya on-premise + Azure para analítica

3. PLANIFICACIÓN DE SISTEMAS INFORMÁTICOS

3.1. Ciclo de Planificación

La planificación de sistemas informáticos es el proceso de definir requisitos, dimensionar recursos y proyectar crecimiento para satisfacer necesidades organizativas.

Fases de Planificación de un Sistema (Ejemplo: Nueva Versión Diraya)
FASE 1: ANÁLISIS DE REQUISITOS (2-3 meses)
├─ Funcionales: ¿Qué debe hacer?
│  • Gestión consultas teleconsulta
│  • Integración con wearables
│  • Receta crónica automatizada
├─ No Funcionales: ¿Cómo debe comportarse?
│  • Rendimiento: <2s tiempo respuesta
│  • Disponibilidad: 99.95% (4.4h/año downtime)
│  • Concurrencia: 5.000 usuarios simultáneos
│  • Seguridad: ENS Categoría ALTA
└─ Restricciones: Presupuesto, tiempo, normativa

FASE 2: DISEÑO ARQUITECTÓNICO (1-2 meses)
├─ Arquitectura lógica (capas, componentes)
├─ Arquitectura física (servidores, redes, almacenamiento)
├─ Dimensionamiento recursos
└─ Estrategia alta disponibilidad/escalabilidad

FASE 3: DIMENSIONAMIENTO Y CAPACITY PLANNING
├─ Estimar carga: Usuarios, transacciones/hora, datos
├─ Calcular recursos: CPU, RAM, disco, red
├─ Proyectar crecimiento: 3-5 años
└─ Costes: CAPEX (inversión) + OPEX (operación)

FASE 4: ANÁLISIS MAKE vs BUY vs CLOUD
├─ Desarrollar a medida
├─ Comprar solución empaquetada
├─ Contratar SaaS
└─ Híbrido

FASE 5: PLAN DE IMPLEMENTACIÓN
├─ Cronograma (fases, hitos)
├─ Asignación recursos (equipo, presupuesto)
├─ Gestión riesgos
└─ Plan migración datos

FASE 6: MONITORIZACIÓN POST-IMPLEMENTACIÓN
├─ KPIs rendimiento
├─ Ajustes capacity
└─ Lessons learned

3.2. Capacity Planning (Planificación de Capacidad)

Proceso de determinar recursos necesarios para satisfacer demanda actual y futura.

Fórmula Básica de Capacidad

Capacidad Requerida = Demanda × (1 + % Crecimiento) × Factor Pico / Utilización Objetivo

Ejemplo: Demanda actual 1000 TPS, crecimiento 20%/año, picos 3x, utilización 70%

Capacidad = 1000 × 1.2 × 3 / 0.7 = 5,143 TPS

3.3. Metodologías de Estimación

📊 Bottom-Up (De abajo arriba)

Partir de componentes individuales y sumar

  • Ventaja: Precisión
  • Desventaja: Complejo, lento
  • Uso: Sistemas nuevos con requisitos detallados

📈 Top-Down (De arriba abajo)

Partir de requisitos globales y desglosar

  • Ventaja: Rápido, visión holística
  • Desventaja: Menos preciso
  • Uso: Estimaciones iniciales, estudios viabilidad

3.4. Herramientas de Planificación

  • Benchmarking: Comparar con sistemas similares (TPC-C, SPECint)
  • Modelos analíticos: Teoría de colas, ley de Little
  • Simulación: Modelar sistema y simular carga (LoadRunner, JMeter)
  • Pruebas de carga reales: Entorno pre-producción con datos reales
  • Monitorización histórica: Analizar tendencias consumo recursos

4. CAPACIDAD, RENDIMIENTO, FLEXIBILIDAD, ESCALABILIDAD Y ALTA DISPONIBILIDAD

4.1. Capacidad

Capacidad es la cantidad máxima de trabajo que un sistema puede procesar en condiciones especificadas.

📏 Métricas de Capacidad

  • Throughput: Transacciones/segundo (TPS), peticiones/segundo (RPS)
  • Usuarios concurrentes: Número simultáneo soportado
  • Volumen de datos: GB/TB almacenables, procesables
  • Ancho de banda: Mbps/Gbps de red
  • IOPS: Operaciones E/S por segundo en discos
Ejemplo Capacidad Diraya (hipotético)
CAPACIDAD ACTUAL (2025):
• Usuarios concurrentes:     4.500
• Transacciones/segundo:     1.200 TPS
• Almacenamiento BBDD:       80 TB
• Crecimiento anual datos:   15%
• Pico demanda (09:00-10:00): 2.5x promedio

PROYECCIÓN 2027:
• Usuarios concurrentes:     6.000 (+33%)
• Transacciones/segundo:     1.800 TPS (+50%)
• Almacenamiento necesario:  106 TB
• Inversión requerida:       Ampliar cluster BBDD + 2 nodos app

4.2. Rendimiento (Performance)

Rendimiento mide qué tan rápido el sistema ejecuta tareas.

Métrica Definición Objetivo SAS (ejemplo)
Latencia Tiempo desde petición hasta respuesta Diraya: <2s (percentil 95)
Throughput Volumen procesado por unidad tiempo Receta electrónica: >500 TPS
Tiempo de respuesta Latencia percibida por usuario ClicSalud+: <3s carga página
Utilización recursos % uso CPU, RAM, disco, red CPU: <70% promedio, <90% picos
Tasa de error % peticiones fallidas <0.1% (1 de cada 1000)

⚠️ Ley de Amdahl (Limitación del Paralelismo)

Gene Amdahl demostró que la mejora de rendimiento por paralelización está limitada por la parte secuencial:

Speedup = 1 / ((1-P) + P/N)

Donde P = fracción paralel izable, N = nº procesadores

Implicación: Si solo 50% es paralelizable, con infinitos procesadores solo logras 2x mejora

4.3. Flexibilidad

Flexibilidad es la capacidad del sistema para adaptarse a cambios de requisitos, carga o entorno sin rediseño completo.

  • Configurabilidad: Parámetros ajustables sin recompilar
  • Modularidad: Componentes intercambiables
  • Extensibilidad: Añadir funcionalidad fácilmente
  • Portabilidad: Migrar entre plataformas (Windows↔Linux, on-premise↔cloud)

4.4. Escalabilidad

Escalabilidad es la capacidad de crecer (o decrecer) para manejar carga creciente (o decreciente) manteniendo rendimiento.

⬆️ Escalabilidad Vertical (Scale Up)

Concepto: Añadir recursos a UN servidor

  • Más CPU cores
  • Más RAM
  • Disco más rápido

Ventajas:

  • ✅ Simple (no cambios arquitectónicos)
  • ✅ Sin complejidad distribución

Desventajas:

  • ❌ Límite físico hardware
  • ❌ Punto único de fallo
  • ❌ Coste no lineal (el doble de RAM puede costar 3x)

➡️ Escalabilidad Horizontal (Scale Out)

Concepto: Añadir MÁS servidores

  • Cluster de N nodos
  • Load balancer distribuye carga
  • Cada nodo es commodity hardware

Ventajas:

  • ✅ Sin límite teórico
  • ✅ Tolerancia a fallos (redundancia)
  • ✅ Coste lineal escalable

Desventajas:

  • ❌ Complejidad arquitectónica
  • ❌ Problemas consistencia/sincronización
  • ❌ No todo es paralelizable (Amdahl)

🎯 Aplicación en el SAS

Vertical: Base de datos Diraya (Oracle RAC en servidores potentes)

Horizontal: Servidores web ClicSalud+ (cluster de nodos detrás de load balancer, escala según demanda)

4.5. Alta Disponibilidad (High Availability - HA)

Alta disponibilidad es la capacidad de un sistema para permanecer operativo el máximo tiempo posible, minimizando interrupciones.

Cálculo de Disponibilidad

Disponibilidad (%) = (Tiempo Operativo / Tiempo Total) × 100
Uptime (%) = (1 - Downtime Permitido/Año) × 100
Disponibilidad Downtime/Año Downtime/Mes Aplicación
99% ("Two nines") 3.65 días 7.2 horas Sistemas no críticos
99.9% ("Three nines") 8.76 horas 43.2 minutos Aplicaciones empresariales
99.95% 4.38 horas 21.6 minutos Diraya (objetivo SAS)
99.99% ("Four nines") 52.56 minutos 4.32 minutos Receta electrónica
99.999% ("Five nines") 5.26 minutos 26 segundos Sistemas críticos telcos/finanzas

💰 Coste de Disponibilidad

Cada "nine" adicional puede duplicar o triplicar el coste:

  • 99% → 99.9%: +50-100% coste (redundancia básica)
  • 99.9% → 99.99%: +100-200% coste (redundancia geográfica, failover automático)
  • 99.99% → 99.999%: +200-400% coste (arquitectura activa-activa multi-región, sin SPOF)

Decisión clave: Equilibrar requisitos de negocio con presupuesto disponible

4.5.1. Técnicas de Alta Disponibilidad

  • Redundancia Hardware: Fuentes alimentación, discos (RAID), redes duplicadas
  • Clustering: Múltiples nodos (activo-activo o activo-pasivo)
  • Load Balancing: Distribución carga entre nodos
  • Failover Automático: Detección fallo y conmutación sin intervención humana
  • Replicación Datos: Síncrona (sin pérdida) o asíncrona (mínima pérdida)
  • Backup y Recuperación: RPO (Recovery Point Objective), RTO (Recovery Time Objective)
  • Disaster Recovery (DR): Sitio secundario geográficamente separado

5. CONCEPTOS Y FUNCIONALIDADES BÁSICAS DE UNIDADES CENTRALES MULTIUSUARIO

5.1. Definición de Sistema Multiusuario

Un sistema multiusuario es aquel que permite que múltiples usuarios accedan simultáneamente a recursos compartidos (CPU, memoria, almacenamiento, periféricos) de forma concurrente, con aislamiento y seguridad entre sesiones.

🏢 Características Fundamentales

  • Multiprocesamiento: Ejecutar múltiples procesos concurrentemente
  • Multitarea: Cambio rápido entre procesos (time-sharing)
  • Multiusuario: Múltiples usuarios simultáneos, cada uno con sesión aislada
  • Protección: Memoria aislada, permisos, cuotas recursos
  • Contabilidad: Registro uso recursos por usuario/aplicación

5.2. Arquitectura de Sistemas Multiusuario

Arquitectura Típica de un Servidor Multiusuario
┌─────────────────────────────────────────────────────────┐
│               CAPA DE USUARIO                           │
│  ┌──────────┐  ┌──────────┐  ┌──────────┐             │
│  │ Usuario 1│  │ Usuario 2│  │ Usuario N│  (Sesiones) │
│  │ Proceso A│  │ Proceso B│  │ Proceso Z│             │
│  └────┬─────┘  └────┬─────┘  └────┬─────┘             │
└───────┼─────────────┼─────────────┼───────────────────┘
        │             │             │
┌───────▼─────────────▼─────────────▼───────────────────┐
│          SISTEMA OPERATIVO (KERNEL)                    │
│  ┌──────────────────────────────────────────────────┐ │
│  │  PLANIFICADOR DE PROCESOS (Scheduler)            │ │
│  │  • Round-robin, prioridades                      │ │
│  │  • Time-slicing (quantum típico: 10-100ms)       │ │
│  └──────────────────────────────────────────────────┘ │
│  ┌──────────────────────────────────────────────────┐ │
│  │  GESTIÓN DE MEMORIA                              │ │
│  │  • Memoria virtual (paginación/segmentación)     │ │
│  │  • Protección entre procesos (MMU)               │ │
│  │  • Swap/paginación a disco                       │ │
│  └──────────────────────────────────────────────────┘ │
│  ┌──────────────────────────────────────────────────┐ │
│  │  GESTIÓN DE E/S                                  │ │
│  │  • Drivers dispositivos                          │ │
│  │  • Buffering, spooling (colas impresión)         │ │
│  │  • DMA (Direct Memory Access)                    │ │
│  └──────────────────────────────────────────────────┘ │
│  ┌──────────────────────────────────────────────────┐ │
│  │  SISTEMA DE ARCHIVOS                             │ │
│  │  • Permisos (rwx, ACLs)                          │ │
│  │  • Cuotas por usuario                            │ │
│  │  • Journaling (ext4, NTFS, XFS)                  │ │
│  └──────────────────────────────────────────────────┘ │
│  ┌──────────────────────────────────────────────────┐ │
│  │  SEGURIDAD Y AUDITORÍA                           │ │
│  │  • Autenticación (PAM, LDAP, Kerberos)           │ │
│  │  • Autorización (grupos, roles)                  │ │
│  │  • Auditoría (logs syslog, auditd)               │ │
│  └──────────────────────────────────────────────────┘ │
└────────────────────┬───────────────────────────────────┘
                     │
┌────────────────────▼───────────────────────────────────┐
│                  HARDWARE                              │
│  • CPUs multi-core (sockets múltiples)                 │
│  • RAM (256GB - 2TB típico servidores)                 │
│  • Almacenamiento (SAN, NAS, local RAID)               │
│  • Red (1Gbps - 100Gbps)                               │
└────────────────────────────────────────────────────────┘

5.3. Funcionalidades Clave

5.3.1. Planificación de Procesos (Scheduling)

El planificador decide qué proceso ejecuta en qué momento. Algoritmos principales:

Algoritmo Descripción Ventajas Desventajas
FCFS (First Come First Served) Orden de llegada Simple, justo Convoy effect (proceso largo bloquea cortos)
Round-Robin Turno circular con quantum fijo Equitativo, baja latencia Context switch overhead si quantum muy pequeño
Prioridades Procesos con mayor prioridad primero Respuesta rápida a críticos Starvation de baja prioridad
Multinivel Varias colas con prioridades diferentes Flexible, ajustable Complejo configurar
CFS (Completely Fair Scheduler) Linux moderno: tiempo CPU proporcional a peso Muy justo, escalable Overhead en cálculos

5.3.2. Gestión de Memoria Virtual

Permite ejecutar procesos cuyo tamaño total supera la RAM física.

🧠 Técnicas de Memoria Virtual

  • Paginación: Memoria dividida en páginas fijas (4KB, 2MB, 1GB)
    • Tabla de páginas (PT) mapea virtuales→físicas
    • TLB (Translation Lookaside Buffer) caché PT
    • Page fault → cargar desde disco (swap)
  • Segmentación: Memoria en segmentos lógicos (código, datos, pila)
    • Cada segmento puede crecer dinámicamente
    • Protección por segmento
  • Híbrido: Paginación + Segmentación (x86-64 usa paginación principalmente)

5.3.3. Mecanismos de Protección

  • Anillos de protección (x86):
    • Ring 0: Kernel (máximos privilegios)
    • Ring 1-2: Drivers, servicios (poco usado)
    • Ring 3: Aplicaciones usuario (mínimos privilegios)
  • Permisos de archivo: Unix (rwx para owner/group/others), Windows (ACLs NTFS)
  • Cuotas de disco: Limitar espacio por usuario/grupo
  • Limits de recursos: CPU time, memoria, procesos, archivos abiertos (ulimit en Linux)

5.4. Mainframes: El Paradigma del Multiusuario

Los mainframes son computadores de gran escala diseñados específicamente para procesamiento multiusuario masivo, transaccional y de alta disponibilidad.

🏛️ Características Distintivas de Mainframes

  • ✅ RAS (Reliability, Availability, Serviceability): 99.999% uptime, mantenimiento sin parada
  • ✅ Escalabilidad masiva: Hasta 190 cores (IBM z16), 40TB RAM
  • ✅ I/O intensivo: Miles de dispositivos concurrentes, channels especializados
  • ✅ Seguridad hardware: Cifrado integrado, secure boot, LPAR aisladas
  • ✅ Virtualización nativa: z/VM ejecutando cientos LPARs
  • ✅ Compatibilidad 60+ años: Binarios de 1960s aún ejecutables
  • ✅ TCO optimizado: Consolidación, menor espacio/energía, menos administradores

5.4.1. IBM z16 (Generación Actual 2022-)

Característica Especificación
Procesador Telum (7nm), 5.2 GHz, hasta 190 cores configurables
Memoria Hasta 40TB RAM
I/O 2000+ canales, 32 Gbps Fibre Channel, NVMe
Cifrado Pervasive Encryption (todo cifrado por defecto, 0 overhead)
IA integrada AI accelerator on-chip (detección fraude en tiempo real)
SO z/OS, z/VM, z/VSE, Linux on Z
Contenedores Kubernetes nativo, Docker, OpenShift
Coste $200K - $4M+ (según configuración)

5.4.2. Casos de Uso Mainframe

💰 Sector Financiero

  • 71% de transacciones Fortune 500 pasan por mainframe
  • Cajeros automáticos (ATMs)
  • Clearing bancario
  • Bolsas de valores

🏥 Sector Sanitario

  • Historiales clínicos centralizados
  • Sistemas facturación
  • Gestión seguros sanitarios
  • No en SAS (arquitectura distribuida)

🛫 Otros Sectores

  • Aerolíneas (reservas)
  • Seguros
  • Retail (inventarios)
  • Administración pública

📊 Estadísticas Mainframe 2024

  • 10.000+ mainframes activos globalmente
  • 87% Fortune 500 los usa
  • 68% transacciones de tarjetas crédito
  • Procesando 30 mil millones transacciones/día

6. EVOLUCIÓN Y TENDENCIAS DE UNIDADES CENTRALES MULTIUSUARIO

6.1. Evolución Histórica

Línea Temporal de Sistemas Multiusuario
1964: IBM SYSTEM/360
• Primera familia compatible de mainframes
• Concepto de arquitectura (ISA separada de implementación)
• Multiprogramación (varios programas en memoria)
• Revolución: Un SO para toda la línea

1970s: MINICOMPUTADORAS
• DEC PDP-11, VAX
• Más pequeños, baratos que mainframes
• Unix nace en PDP-7 (1969)
• Departamentales, universidades

1980s: UNIX Y CLIENTE-SERVIDOR
• Unix se estandariza (System V, BSD)
• Estaciones de trabajo (Sun, HP)
• Arquitectura cliente-servidor emerge
• PCs (IBM PC 1981) empiezan a competir

1990s: SERVIDORES x86 Y LINUX
• Windows NT Server (1993): multiusuario en x86
• Linux (1991): Unix gratis en commodity hardware
• Blade servers: densidad rack
• Internet → servidores web

2000s: VIRTUALIZACIÓN Y CONSOLIDACIÓN
• VMware ESX (2001): virtualización x86 madura
• Consolidación: 1 físico → 10-50 VMs
• Reducción costes, mayor utilización
• Xen, KVM (virtualizadores open source)

2010s: CLOUD COMPUTING
• AWS (2006), Azure (2010), GCP (2011)
• IaaS: Servidores bajo demanda, elásticos
• Multitenancy extremo: cientos de clientes/servidor físico
• Contenedores (Docker 2013): virtualización ligera

2020s: CLOUD NATIVO Y EDGE
• Kubernetes: orquestación contenedores
• Serverless (FaaS): Lambda, Azure Functions
• Edge computing: procesamiento cerca del dato
• Mainframes modernizados (Linux on Z, contenedores)

6.2. Tendencias Actuales (2025)

6.2.1. Modernización de Mainframes

🔄 El Mainframe NO está Muerto

Contrario a predicciones de los 90s, los mainframes evolucionan:

  • ✅ Linux on Z: 2/3 de cargas mainframe ahora Linux (no solo z/OS)
  • ✅ Contenedores: Docker, Kubernetes nativos en z16
  • ✅ APIs REST: Exponer aplicaciones COBOL como microservicios
  • ✅ Híbrido: Mainframe backend + cloud frontend
  • ✅ DevOps: CI/CD para mainframe (Git, Jenkins)
  • ✅ IA integrada: Aceleradores on-chip (z16 Telum)

6.2.2. Arquitecturas Híbridas y Multi-Cloud

La tendencia NO es "migrar todo a cloud", sino arquitecturas híbridas:

  • On-premise: Datos sensibles, baja latencia, compliance (Diraya historial clínico)
  • Private cloud: Virtualización interna (OpenStack, VMware)
  • Public cloud: Cargas variables, desarrollo, analytics (Azure para BI del SAS)
  • Multi-cloud: Evitar vendor lock-in, DR geográfico

6.2.3. Computación en el Edge

Edge computing procesa datos cerca de su origen, complementando (no reemplazando) servidores centrales:

☁️ Cloud (Centralizado)

  • Potencia ilimitada
  • Almacenamiento masivo
  • Analytics complejos
  • Latencia 50-500ms

📍 Edge (Distribuido)

  • Latencia <10ms
  • Funcionamiento offline
  • Privacidad (datos locales)
  • Reducción ancho banda

Ejemplo sanitario: Dispositivos médicos IoT (monitores) procesan datos vitales en edge (detección anomalías tiempo real) y envían resumen a cloud/Diraya para análisis histórico.

6.2.4. Inteligencia Artificial y Machine Learning

Los sistemas multiusuario integran aceleradores IA:

  • GPUs: NVIDIA A100, H100 para entrenamiento modelos
  • TPUs: Google Tensor Processing Units
  • AI accelerators: IBM Telum (mainframe), Intel Habana
  • Inferencia en producción: Modelos ML embebidos en aplicaciones transaccionales

6.2.5. Sostenibilidad y Green IT

🌱 Eficiencia Energética

  • PUE (Power Usage Effectiveness): Meta <1.2 (Google ya 1.1)
  • Refrigeración líquida: Inmersión servidores (Microsoft Project Natick)
  • Energías renovables: 100% renovable en Google, Apple, Microsoft datacenters
  • Optimización carga: Migrar VMs a DCs con exceso solar/eólico
  • Hardware eficiente: ARM servers (AWS Graviton: 60% menos energía que x86)

7. SISTEMAS DEPARTAMENTALES Y GRANDES SISTEMAS CENTRALES

7.1. Sistemas Departamentales

Sistemas departamentales son soluciones informáticas de alcance limitado, diseñadas para satisfacer necesidades de un departamento o unidad organizativa.

Característica Sistemas Departamentales
Alcance Departamento, unidad de negocio (50-500 usuarios)
Hardware Servidores mid-range (1-4 sockets, 128-512GB RAM)
Coste $10K - $200K
Disponibilidad 99-99.9% (downtime planificado)
Administración 1-2 personas (a veces compartido)
Ejemplos Servidor archivos departamental, aplicación RH local, DB test/desarrollo
Ventajas Agilidad, bajo coste, control local, rápida implementación
Desventajas Silos de información, duplicación, dificulta integración corporativa

7.2. Grandes Sistemas Centrales

Grandes sistemas centrales son infraestructuras que dan servicio a toda la organización o múltiples organizaciones.

Característica Grandes Sistemas Centrales
Alcance Corporativo, multi-organización (1000-1.000.000+ usuarios)
Hardware Mainframes, clusters HPC, mega-datacenters cloud
Coste $500K - $50M+ (infraestructura completa)
Disponibilidad 99.95-99.999% (tolerancia cero a caídas)
Administración Equipos especializados (10-100+ personas)
Ejemplos Core bancario, Diraya SAS, SAP corporativo, AWS/Azure/GCP
Ventajas Economía escala, datos unificados, estandarización, seguridad robusta
Desventajas Alto coste inicial, rigidez, lentitud cambios, complejidad

7.3. Comparativa y Decisión

Matriz de Decisión: Departamental vs Central
CRITERIOS PARA CENTRALIZAR:
✅ Datos requieren integración corporativa
✅ Procesos críticos de negocio
✅ Compliance y auditoría estrictos
✅ Economías de escala (muchos usuarios)
✅ Necesidad de HA (>99.9%)
✅ Seguridad máxima

EJEMPLO SAS: Diraya (historia digital)
→ CENTRAL: Todos los profesionales, datos críticos,
   integración total, máxima seguridad

CRITERIOS PARA DEPARTAMENTAL:
✅ Necesidades específicas de área
✅ Agilidad y rapidez de cambio
✅ Presupuesto limitado
✅ Usuarios limitados a departamento
✅ Datos no sensibles o aislables

EJEMPLO SAS: Sistema gestión almacén específico
→ DEPARTAMENTAL: Solo farmacia hospitalaria,
   no crítico, requisitos únicos

7.4. Tendencia: Lo Mejor de Ambos Mundos

La tendencia moderna es híbrida:

  • Plataforma central corporativa: Infraestructura común (redes, storage, identidad, seguridad)
  • Servicios compartidos: BD, messaging, APIs disponibles para todos
  • Autonomía departamental: Equipos eligen tecnologías dentro de marcos aprobados
  • Gobernanza: Políticas centrales, implementación descentralizada

🎯 Aplicación en el SAS

Central:

  • Diraya (historia digital única Andalucía)
  • BDU (Banco Datos Usuarios)
  • Receta electrónica
  • Portal ClicSalud+

Departamental/Distribuido:

  • Sistemas específicos hospitalarios (PACS local)
  • Aplicaciones unidad investigación
  • Herramientas gestión departamental

Híbrido:

  • Infraestructura CPD central
  • Azure cloud para cargas variables
  • Servicios compartidos (Active Directory, backup, monitorización)

8. CONCLUSIONES

🎯 Ideas Clave para la Oposición

  1. Arquitecturas evolucionan: Mainframe centralizado → Cliente-Servidor → N-capas → Microservicios → Cloud/Híbrido
  2. Planificación es crítica: Capacity planning evita subdimensionamiento (lentitud) y sobredimensionamiento (desperdicio)
  3. 5 conceptos clave: Capacidad, Rendimiento, Flexibilidad, Escalabilidad, Alta Disponibilidad
  4. Escalabilidad: Vertical (scale up: más potencia) vs Horizontal (scale out: más servidores)
  5. Alta disponibilidad: 99.9% = 8.76h/año downtime. Cada "nine" multiplica coste x2-3
  6. Mainframes vivos: IBM z16, Linux on Z, contenedores. NO están obsoletos
  7. Sistemas multiusuario: Multiproceso, multitarea, protección memoria, scheduling
  8. Departamental vs Central: Decisión según alcance, criticidad, integración requerida
  9. Tendencia híbrida: On-premise crítico + Cloud elástico. No todo a cloud
  10. SAS usa ambos: Diraya central + sistemas departamentales + Azure cloud

Conexiones con Otros Temas

  • 🔗 Tema 50 (Fundamentos): Von Neumann es base de toda arquitectura
  • 🔗 Tema ENS: Alta disponibilidad es requisito seguridad ENS ALTO
  • 🔗 Tema Cloud: IaaS/PaaS/SaaS son evolución de arquitecturas multiusuario
  • 🔗 Tema RGPD: Planificación debe considerar protección datos desde diseño
  • 🔗 Tema Virtualización: Permite consolidación y mejor utilización recursos
  • 🔗 Tema Redes: Arquitecturas distribuidas dependen de redes de alto rendimiento

💪 Mensaje Final

Diseñar y planificar sistemas informáticos NO es solo "comprar servidores". Es entender el negocio (¿cuántos usuarios? ¿qué crecimiento?), equilibrar requisitos técnicos con presupuesto, y proyectar a futuro.

Como TFA-STI del SAS, participarás en decisiones que afectan a millones de andaluces: Si Diraya es lento, los médicos no pueden trabajar. Si ClicSalud+ cae, los ciudadanos no piden citas. Si la receta electrónica falla, las farmacias se colapsan.

Planificar bien NO es opcional. Es tu responsabilidad profesional.

9. CUESTIONARIO (30 PREGUNTAS TIPO TEST)

Pregunta 1

¿Qué arquitectura separa el sistema en tres capas: presentación, lógica de negocio y datos?

A) Cliente-servidor de 2 capas
B) Arquitectura N-tier (3 capas) ✓
C) Arquitectura monolítica
D) Peer-to-peer
Respuesta correcta: B
La arquitectura 3 capas (N-tier) separa: 1) Presentación (UI), 2) Lógica de negocio (aplicación), 3) Datos (BBDD). Permite escalabilidad y mantenibilidad independientes.

Pregunta 2

¿Qué significa escalar horizontalmente (scale out)?

A) Añadir más CPU y RAM a un servidor existente
B) Añadir más servidores al sistema ✓
C) Mejorar el software sin cambiar hardware
D) Reducir el número de componentes
Respuesta correcta: B
Scale out (horizontal) = añadir más nodos/servidores. Scale up (vertical) = más recursos en mismo servidor. Horizontal permite crecimiento ilimitado pero añade complejidad.

Pregunta 3

¿Qué porcentaje de disponibilidad corresponde a "four nines"?

A) 99%
B) 99.9%
C) 99.99% ✓
D) 99.999%
Respuesta correcta: C
"Four nines" = 99.99% = 52.56 minutos downtime/año. "Five nines" = 99.999% = 5.26 min/año. Cada "nine" adicional multiplica costes x2-3.

Pregunta 4

¿Cuál es el mainframe actual de IBM (generación 2022-)?

A) IBM z14
B) IBM z15
C) IBM z16 ✓
D) IBM System/360
Respuesta correcta: C
IBM z16 (2022) con procesador Telum, hasta 190 cores, 40TB RAM, IA integrada on-chip, soporte contenedores/Kubernetes nativo.

Pregunta 5

¿Qué algoritmo de planificación de procesos asigna turnos circulares con tiempo fijo (quantum)?

A) FCFS (First Come First Served)
B) Round-Robin ✓
C) Prioridades
D) Shortest Job First
Respuesta correcta: B
Round-Robin asigna quantum fijo (ej: 10ms) a cada proceso en turno circular. Equitativo, usado en sistemas time-sharing multiusuario.

Pregunta 6

¿Qué técnica permite ejecutar procesos cuyo tamaño total supera la RAM física?

A) Multitasking
B) Memoria virtual (paginación/swapping) ✓
C) Caché L2
D) DMA (Direct Memory Access)
Respuesta correcta: B
La memoria virtual usa disco como extensión de RAM, paginando (swapping) bloques entre RAM y disco según demanda. Fundamental en sistemas multiusuario.

Pregunta 7

¿Qué significa RAS en el contexto de mainframes?

A) Rapid Application Server
B) Reliability, Availability, Serviceability ✓
C) Remote Access System
D) Resource Allocation Scheduler
Respuesta correcta: B
RAS (Reliability, Availability, Serviceability) es el principio de diseño de mainframes: máxima fiabilidad, disponibilidad 99.999%, mantenimiento sin parada.

Pregunta 8

¿En qué década apareció la arquitectura cliente-servidor?

A) 1960s
B) 1970s
C) 1980s ✓
D) 1990s
Respuesta correcta: C
Cliente-servidor emerge en los 80s con PCs + estaciones de trabajo + servidores Unix. Reemplaza gradualmente modelo terminal tonto + mainframe centralizado.

Pregunta 9

¿Qué tipo de cliente tiene mucha lógica de aplicación ejecutándose localmente?

A) Cliente pesado (thick/fat client) ✓
B) Cliente ligero (thin client)
C) Cliente web
D) Terminal tonto
Respuesta correcta: A
Cliente pesado ejecuta lógica localmente (app .NET instalada). Cliente ligero solo presenta (navegador web). Thin client: fácil mantenimiento. Thick: mejor UX.

Pregunta 10

¿Qué característica de microservicios permite escalar solo servicios con más carga?

A) Monolitismo
B) Escalado granular ✓
C) Acoplamiento fuerte
D) Base de datos compartida
Respuesta correcta: B
Microservicios permiten escalar cada servicio independientemente. Si "Citas" tiene mucha carga, escalo solo ese servicio sin tocar "Receta" o "Historial".

Pregunta 11

¿Cuántas horas de downtime al año permite una disponibilidad del 99.9%?

A) 87.6 horas
B) 8.76 horas ✓
C) 52.56 minutos
D) 5.26 minutos
Respuesta correcta: B
99.9% = 8.76 horas/año. 99% = 3.65 días/año. 99.99% = 52.56 min/año. 99.999% = 5.26 min/año. Cálculo: (1-0.999) × 365.25 × 24 = 8.76h.

Pregunta 12

¿Qué sistema operativo multiusuario nació en 1969 en un DEC PDP-7?

A) Windows NT
B) Linux
C) Unix ✓
D) z/OS
Respuesta correcta: C
Unix fue creado por Ken Thompson y Dennis Ritchie en Bell Labs (1969) en PDP-7. Linux (1991) es inspirado en Unix. Windows NT (1993). z/OS es mainframe IBM.

Pregunta 13

¿Qué técnica de alta disponibilidad permite conmutar automáticamente a servidor secundario si el primario falla?

A) Load balancing
B) Failover automático ✓
C) Round-robin DNS
D) Sharding
Respuesta correcta: B
Failover automático detecta fallo del primario y activa secundario sin intervención humana. Activo-pasivo: uno trabaja, otro espera. Activo-activo: ambos trabajan.

Pregunta 14

¿Qué arquitectura de mainframe separa recursos físicos en particiones lógicas aisladas?

A) Multicore
B) LPAR (Logical Partition) ✓
C) NUMA
D) SMP
Respuesta correcta: B
LPAR (Logical Partition) en mainframes IBM divide hardware físico en particiones lógicas independientes, cada una ejecutando SO propio (z/OS, Linux, z/VM). Virtualización nativa.

Pregunta 15

¿Qué métrica mide el número de transacciones procesadas por unidad de tiempo?

A) Latencia
B) Throughput ✓
C) Utilización
D) Disponibilidad
Respuesta correcta: B
Throughput = volumen procesado/tiempo (TPS: transacciones/segundo, RPS: requests/segundo). Latencia = tiempo respuesta. Utilización = % recurso usado.

Pregunta 16

¿Qué ley establece que el speedup por paralelización está limitado por la parte secuencial?

A) Ley de Amdahl ✓
B) Ley de Moore
C) Ley de Little
D) Ley de Shannon
Respuesta correcta: A
Ley de Amdahl: Speedup = 1/((1-P)+P/N). Si 50% es paralelo, con infinitos cores solo logras 2x mejora. Límite fundamental del paralelismo.

Pregunta 17

¿Qué modelo cloud proporciona infraestructura virtualizada (VMs, almacenamiento, redes)?

A) IaaS (Infrastructure as a Service) ✓
B) PaaS (Platform as a Service)
C) SaaS (Software as a Service)
D) FaaS (Function as a Service)
Respuesta correcta: A
IaaS: VMs (AWS EC2, Azure VMs). PaaS: Plataforma desarrollo (Heroku). SaaS: Aplicación completa (Microsoft 365). FaaS: Funciones serverless (Lambda).

Pregunta 18

¿Qué procesador integra aceleradores IA on-chip en el IBM z16?

A) POWER10
B) Telum ✓
C) z15
D) Graviton
Respuesta correcta: B
Telum (7nm, 5.2GHz) es el procesador del z16 con AI accelerator integrado para inferencia en tiempo real (detección fraude). Hasta 190 cores configurables.

Pregunta 19

¿Qué anillo de protección en x86 tiene máximos privilegios?

A) Ring 0 ✓
B) Ring 1
C) Ring 2
D) Ring 3
Respuesta correcta: A
Ring 0: Kernel (máximos privilegios). Ring 1-2: Drivers (poco usado). Ring 3: Aplicaciones usuario (mínimos privilegios). Mecanismo protección hardware.

Pregunta 20

¿Qué sistema de archivos con journaling es estándar en Linux moderno?

A) FAT32
B) NTFS
C) ext4 ✓
D) HFS+
Respuesta correcta: C
ext4 (fourth extended filesystem) es estándar Linux con journaling, soporte archivos grandes, mejor rendimiento. NTFS es Windows. FAT32 es legacy. HFS+ es macOS (reemplazado por APFS).

Pregunta 21

¿Qué porcentaje de transacciones de Fortune 500 pasan por mainframes según estadísticas 2024?

A) 30%
B) 50%
C) 71% ✓
D) 90%
Respuesta correcta: C
Según IBM (2024), 71% transacciones Fortune 500 pasan por mainframe. 87% Fortune 500 los usa. 68% transacciones tarjetas crédito. 30 mil millones transacciones/día globalmente.

Pregunta 22

¿Qué arquitectura usa memoria separada para instrucciones y datos?

A) Von Neumann
B) Harvard ✓
C) RISC
D) CISC
Respuesta correcta: B
Harvard separa físicamente memoria instrucciones y datos. Von Neumann las unifica. Arquitecturas modernas usan Harvard modificada (caché separada L1-I/L1-D, RAM unificada).

Pregunta 23

¿Qué tecnología permite consolidar múltiples servidores físicos en uno usando máquinas virtuales?

A) Clustering
B) Virtualización ✓
C) Load balancing
D) Replicación
Respuesta correcta: B
La virtualización (VMware, KVM, Hyper-V) permite ejecutar múltiples VMs en un servidor físico, mejorando utilización (de ~15% a ~70%), reduciendo costes hardware/energía.

Pregunta 24

¿Qué familia de mainframes IBM lanzada en 1964 revolucionó el concepto de arquitectura compatible?

A) IBM 701
B) IBM System/360 ✓
C) IBM AS/400
D) IBM z/OS
Respuesta correcta: B
System/360 (1964) introdujo arquitectura compatible: un SO para toda la línea, múltiples modelos con misma ISA. Concepto revolucionario que permitió actualizaciones sin reescribir software.

Pregunta 25

¿Qué significa PUE en eficiencia energética de datacenters?

A) Performance Usage Efficiency
B) Power Usage Effectiveness ✓
C) Processing Unit Efficiency
D) Primary Usage Energy
Respuesta correcta: B
PUE = Energía total datacenter / Energía IT. PUE ideal = 1.0 (100% a IT). PUE 2.0 = 50% a IT, 50% refrigeración/iluminación. Google logra 1.1. Meta: <1.2.

Pregunta 26

¿Qué orquestador es estándar de facto para gestionar contenedores en producción?

A) Docker Swarm
B) Kubernetes ✓
C) Apache Mesos
D) Nomad
Respuesta correcta: B
Kubernetes (K8s) domina orquestación contenedores: auto-scaling, self-healing, service discovery, rolling updates. Soportado por todos los clouds (AKS, EKS, GKE).

Pregunta 27

¿Qué característica permite a mainframes ejecutar código de los años 60 sin cambios?

A) Emulación
B) Compatibilidad binaria hacia atrás ✓
C) Recompilación automática
D) Virtualización
Respuesta correcta: B
Los mainframes IBM mantienen compatibilidad binaria desde System/360 (1964). Binarios COBOL de los 60s ejecutan en z16 (2022) sin cambios. Garantía de inversión software.

Pregunta 28

¿Qué modelo de despliegue combina on-premise y cloud público?

A) Public cloud
B) Private cloud
C) Hybrid cloud ✓
D) Community cloud
Respuesta correcta: C
Hybrid cloud integra on-premise + cloud público. Ejemplo SAS: Diraya on-premise (datos sensibles) + Azure cloud (analytics, desarrollo). Flexibilidad + control + elasticidad.

Pregunta 29

¿Qué paradigma procesa datos cerca de su origen en lugar de enviarlos a datacenter central?

A) Cloud computing
B) Edge computing ✓
C) Fog computing
D) Grid computing
Respuesta correcta: B
Edge computing procesa en el borde de la red (IoT, dispositivos) con latencia <10ms. Complementa (no reemplaza) cloud. Fog computing es capa intermedia edge-cloud.

Pregunta 30

¿Qué objetivo tiene el "capacity planning"?

A) Reducir costes a mínimo absoluto
B) Dimensionar recursos para satisfacer demanda actual y futura ✓
C) Maximizar utilización al 100%
D) Comprar siempre el hardware más potente
Respuesta correcta: B
Capacity planning proyecta crecimiento (usuarios, transacciones, datos) y dimensiona recursos para satisfacer demanda sin subdimensionar (lentitud) ni sobredimensionar (desperdicio).

10. MAPA CONCEPTUAL

┌─────────────────────────────────────────────────────────────────────────────────┐
│    TEMA 51: ARQUITECTURAS Y PLANIFICACIÓN DE SISTEMAS INFORMÁTICOS             │
└─────────────────────────────────────────────────────────────────────────────────┘
                                        │
                ┌───────────────────────┼───────────────────────┐
                │                       │                       │
         ┌──────▼──────┐         ┌─────▼──────┐         ┌─────▼──────┐
         │ARQUITECTURAS│         │PLANIFICACIÓN│         │  SISTEMAS  │
         │  BÁSICAS    │         │             │         │MULTIUSUARIO│
         └──────┬──────┘         └─────┬──────┘         └─────┬──────┘
                │                      │                       │
    ┌───────────┼──────────┐      ┌───┴────┐          ┌───────┴────────┐
    │           │          │      │        │          │                │
┌───▼────┐ ┌───▼─────┐ ┌──▼───┐ ┌▼──────┐ ┌▼───────┐ ┌▼──────┐  ┌────▼───────┐
│Cliente │ │N-Capas │ │Micro-│ │Capacity│ │Métricas│ │Mainframe│ │Departament.│
│Servidor│ │        │ │servic│ │Planning│ │        │ │IBM z16  │ │vs Central  │
│        │ │3-tier  │ │      │ │        │ │HA/Scale│ │         │ │            │
└────────┘ └────────┘ └──────┘ └────────┘ └────────┘ └─────────┘ └────────────┘

┌─────────────────────────────────────────────────────────────────────────────────┐
│                    EVOLUCIÓN DE ARQUITECTURAS                                   │
├─────────────────────────────────────────────────────────────────────────────────┤
│                                                                                 │
│  1960s-70s: MAINFRAME CENTRALIZADO                                              │
│  ┌─────────────────┐                                                            │
│  │   MAINFRAME     │  ← Todo centralizado                                       │
│  │   IBM S/360     │                                                            │
│  └────────┬────────┘                                                            │
│           │                                                                     │
│      Terminales tontos                                                          │
│                                                                                 │
│  1980s: CLIENTE-SERVIDOR                                                        │
│  ┌─────────┐  ◄──►  ┌─────────┐                                               │
│  │ Cliente │  LAN   │ Servidor│  ← Distribución carga                          │
│  │   PC    │        │  Unix   │                                                │
│  └─────────┘        └─────────┘                                                │
│                                                                                 │
│  2000s: N-CAPAS Y WEB                                                           │
│  [Browser] ◄─► [Web Server] ◄─► [App Server] ◄─► [DB Server]                 │
│                                                                                 │
│  2010s: CLOUD Y VIRTUALIZACIÓN                                                  │
│  ┌───────────────────────────────┐                                             │
│  │     CLOUD (AWS/Azure/GCP)     │  ← Elasticidad, IaaS/PaaS/SaaS             │
│  │  ┌────┐ ┌────┐ ┌────┐ ┌────┐ │                                             │
│  │  │ VM │ │ VM │ │ VM │ │ VM │ │  ← Consolidación                            │
│  │  └────┘ └────┘ └────┘ └────┘ │                                             │
│  └───────────────────────────────┘                                             │
│                                                                                 │
│  2020s: MICROSERVICIOS Y CONTENEDORES                                           │
│  ┌────────────  API GATEWAY  ────────────┐                                     │
│  │     │        │        │        │       │                                     │
│  │  [Serv.] [Serv.] [Serv.] [Serv.]     │  ← Escalado granular                │
│  │  Docker  Docker  Docker  Docker       │                                     │
│  └────────────────────────────────────────┘                                     │
│           Orquestación: Kubernetes                                              │
└─────────────────────────────────────────────────────────────────────────────────┘

┌─────────────────────────────────────────────────────────────────────────────────┐
│               MÉTRICAS CLAVE DE SISTEMAS INFORMÁTICOS                           │
├─────────────────────────────────────────────────────────────────────────────────┤
│                                                                                 │
│  📏 CAPACIDAD                                                                   │
│     • Throughput: TPS (transacciones/segundo)                                   │
│     • Usuarios concurrentes máximos                                             │
│     • Volumen datos (TB almacenables/procesables)                               │
│     • IOPS (operaciones E/S disco/segundo)                                      │
│                                                                                 │
│  ⚡ RENDIMIENTO (Performance)                                                   │
│     • Latencia: Tiempo petición→respuesta                                       │
│     • Tiempo respuesta percentil 95: <2s (objetivo típico)                      │
│     • Utilización recursos: CPU <70% promedio, <90% picos                       │
│     • Tasa error: <0.1%                                                         │
│                                                                                 │
│  🔀 FLEXIBILIDAD                                                                │
│     • Configurabilidad sin recompilar                                           │
│     • Modularidad (componentes intercambiables)                                 │
│     • Portabilidad (Windows↔Linux, on-premise↔cloud)                            │
│                                                                                 │
│  📈 ESCALABILIDAD                                                               │
│     ┌──────────────────────────────────────────────────┐                       │
│     │  VERTICAL (Scale Up)    vs   HORIZONTAL (Scale Out)│                     │
│     │  Más recursos 1 servidor     Más servidores      │                       │
│     │  ✅ Simple                    ✅ Sin límite       │                       │
│     │  ❌ Límite físico             ❌ Complejidad      │                       │
│     │  ❌ Punto fallo único         ✅ Tolerancia fallos│                       │
│     └──────────────────────────────────────────────────┘                       │
│                                                                                 │
│  🟢 ALTA DISPONIBILIDAD (HA)                                                    │
│     99%      = 3.65 días/año downtime                                           │
│     99.9%    = 8.76 horas/año (aplicaciones empresariales)                      │
│     99.95%   = 4.38 horas/año (Diraya SAS)                                      │
│     99.99%   = 52.56 min/año (Receta electrónica)                               │
│     99.999%  = 5.26 min/año (Sistemas críticos)                                 │
│                                                                                 │
│     Técnicas HA:                                                                │
│     • Redundancia hardware (PSU, discos RAID, NICs)                             │
│     • Clustering (activo-activo, activo-pasivo)                                 │
│     • Failover automático                                                       │
│     • Replicación datos (síncrona/asíncrona)                                    │
│     • Disaster Recovery (DR) geográfico                                         │
└─────────────────────────────────────────────────────────────────────────────────┘

┌─────────────────────────────────────────────────────────────────────────────────┐
│                        SISTEMAS MULTIUSUARIO                                    │
├─────────────────────────────────────────────────────────────────────────────────┤
│                                                                                 │
│  CARACTERÍSTICAS:                                                               │
│  • Multiprocesamiento: Múltiples procesos concurrentes                          │
│  • Multitarea: Time-sharing (quantum típico 10-100ms)                           │
│  • Protección: Memoria aislada, permisos, cuotas                                │
│  • Scheduling: Round-robin, prioridades, CFS                                    │
│  • Memoria virtual: Paginación, swap, TLB                                       │
│                                                                                 │
│  MAINFRAMES (IBM z16):                                                          │
│  ┌────────────────────────────────────────────────────────┐                    │
│  │  • Procesador Telum (7nm, 5.2GHz, hasta 190 cores)    │                    │
│  │  • RAM: Hasta 40TB                                    │                    │
│  │  • RAS: 99.999% uptime (5.26 min/año)                 │                    │
│  │  • Virtualización: z/VM, cientos LPARs                │                    │
│  │  • Cifrado pervasivo (0 overhead)                     │                    │
│  │  • IA on-chip (detección fraude tiempo real)          │                    │
│  │  • Kubernetes nativo, contenedores                    │                    │
│  │  • Linux on Z (2/3 de cargas mainframe)               │                    │
│  │  • Compatibilidad binaria 60+ años                    │                    │
│  └────────────────────────────────────────────────────────┘                    │
│                                                                                 │
│  CASOS USO:                                                                     │
│  • 71% transacciones Fortune 500                                                │
│  • 87% Fortune 500 usa mainframes                                               │
│  • 68% transacciones tarjetas crédito                                           │
│  • 30 mil millones transacciones/día globalmente                                │
│  • Banca, seguros, aerolíneas, retail, administración pública                   │
└─────────────────────────────────────────────────────────────────────────────────┘

┌─────────────────────────────────────────────────────────────────────────────────┐
│            DEPARTAMENTAL vs GRANDES SISTEMAS CENTRALES                          │
├─────────────────────────────────────────────────────────────────────────────────┤
│                                                                                 │
│  SISTEMA DEPARTAMENTAL                    SISTEMA CENTRAL                       │
│  ───────────────────────────             ──────────────────                    │
│  • Alcance: 50-500 usuarios              • Alcance: 1000-1M+ usuarios          │
│  • Hardware: Mid-range                   • Hardware: Mainframe/HPC/Cloud       │
│  • Coste: $10K-$200K                     • Coste: $500K-$50M+                  │
│  • HA: 99-99.9%                          • HA: 99.95-99.999%                   │
│  • Admin: 1-2 personas                   • Admin: 10-100+ personas             │
│  • Ventaja: Agilidad, bajo coste         • Ventaja: Economía escala, seguridad │
│  • Desventaja: Silos información         • Desventaja: Alto coste, rigidez     │
│                                                                                 │
│  TENDENCIA ACTUAL: HÍBRIDO                                                      │
│  ┌───────────────────────────────────────────────────┐                         │
│  │  • Plataforma central corporativa (infraestructura│                         │
│  │    común: redes, storage, identidad, seguridad)   │                         │
│  │  • Servicios compartidos (BD, messaging, APIs)    │                         │
│  │  • Autonomía departamental (tecnologías dentro    │                         │
│  │    de marcos aprobados)                           │                         │
│  │  • Gobernanza (políticas centrales, implementa-   │                         │
│  │    ción descentralizada)                          │                         │
│  └───────────────────────────────────────────────────┘                         │
│                                                                                 │
│  APLICACIÓN EN EL SAS:                                                          │
│  • CENTRAL: Diraya, BDU, Receta electrónica, ClicSalud+                         │
│  • DEPARTAMENTAL: Sistemas específicos hospitalarios (PACS local)               │
│  • HÍBRIDO: CPD central on-premise + Azure cloud para cargas variables         │
└─────────────────────────────────────────────────────────────────────────────────┘

┌─────────────────────────────────────────────────────────────────────────────────┐
│                         TENDENCIAS 2025                                         │
├─────────────────────────────────────────────────────────────────────────────────┤
│                                                                                 │
│  🔄 MODERNIZACIÓN MAINFRAMES                                                    │
│     • Linux on Z (2/3 de cargas)                                                │
│     • Contenedores nativos (Docker, Kubernetes)                                 │
│     • APIs REST (exponer COBOL como microservicios)                             │
│     • DevOps para mainframe (Git, CI/CD)                                        │
│                                                                                 │
│  ☁️ ARQUITECTURAS HÍBRIDAS Y MULTI-CLOUD                                       │
│     • On-premise: Datos sensibles, baja latencia                                │
│     • Private cloud: Virtualización interna                                     │
│     • Public cloud: Cargas variables, desarrollo                                │
│     • Multi-cloud: Evitar vendor lock-in                                        │
│                                                                                 │
│  📍 EDGE COMPUTING                                                              │
│     • Procesamiento cerca del dato (<10ms latencia)                             │
│     • Funcionamiento offline                                                    │
│     • Privacidad (datos locales)


│                                                                                 │
│  🤖 INTELIGENCIA ARTIFICIAL                                                     │
│     • GPUs para entrenamiento (NVIDIA A100, H100)                               │
│     • TPUs (Google Tensor Processing Units)                                     │
│     • Aceleradores mainframe (IBM Telum)                                        │
│     • Inferencia en producción integrada                                        │
│                                                                                 │
│  🌱 SOSTENIBILIDAD Y GREEN IT                                                   │
│     • PUE <1.2 (Google ya 1.1)                                                  │
│     • Refrigeración líquida (inmersión servidores)                              │
│     • 100% energías renovables (Google, Apple, Microsoft)                       │
│     • ARM servers (AWS Graviton: -60% energía vs x86)                           │
└─────────────────────────────────────────────────────────────────────────────────┘

┌─────────────────────────────────────────────────────────────────────────────────┐
│                   PLANIFICACIÓN DE SISTEMAS INFORMÁTICOS                        │
├─────────────────────────────────────────────────────────────────────────────────┤
│                                                                                 │
│  FASES DEL CICLO DE PLANIFICACIÓN:                                              │
│                                                                                 │
│  1️⃣ ANÁLISIS DE REQUISITOS                                                     │
│     • Funcionales: ¿Qué debe hacer?                                             │
│     • No funcionales: Rendimiento, disponibilidad, seguridad                    │
│     • Restricciones: Presupuesto, tiempo, normativa                             │
│                                                                                 │
│  2️⃣ DISEÑO ARQUITECTÓNICO                                                      │
│     • Arquitectura lógica (componentes, capas)                                  │
│     • Arquitectura física (servidores, redes, storage)                          │
│     • Estrategia HA/DR                                                          │
│                                                                                 │
│  3️⃣ CAPACITY PLANNING                                                          │
│     ┌────────────────────────────────────────────────────┐                     │
│     │ Capacidad = Demanda × (1+%Crec) × FactorPico      │                     │
│     │            ────────────────────────────────        │                     │
│     │                 Utilización Objetivo               │                     │
│     └────────────────────────────────────────────────────┘                     │
│     • Estimar carga (usuarios, TPS, datos)                                      │
│     • Calcular recursos (CPU, RAM, disco, red)                                  │
│     • Proyectar crecimiento 3-5 años                                            │
│     • CAPEX (inversión) + OPEX (operación)                                      │
│                                                                                 │
│  4️⃣ MAKE vs BUY vs CLOUD                                                       │
│     • Desarrollar a medida                                                      │
│     • Comprar solución empaquetada (COTS)                                       │
│     • Contratar SaaS                                                            │
│     • Híbrido (lo mejor de cada opción)                                         │
│                                                                                 │
│  5️⃣ IMPLEMENTACIÓN                                                             │
│     • Cronograma (fases, hitos)                                                 │
│     • Gestión riesgos                                                           │
│     • Plan migración datos                                                      │
│                                                                                 │
│  6️⃣ MONITORIZACIÓN Y AJUSTE                                                    │
│     • KPIs rendimiento                                                          │
│     • Ajustes capacity continuos                                                │
│     • Lessons learned                                                           │
│                                                                                 │
│  METODOLOGÍAS DE ESTIMACIÓN:                                                    │
│  • Bottom-Up: Desde componentes individuales (preciso, lento)                   │
│  • Top-Down: Desde requisitos globales (rápido, menos preciso)                  │
│  • Benchmarking: Comparar con sistemas similares                                │
│  • Simulación: Modelar y simular carga                                          │
│  • Pruebas carga reales: Entorno pre-producción                                 │
└─────────────────────────────────────────────────────────────────────────────────┘

                          🎯 SÍNTESIS EJECUTIVA 🎯
                 ═══════════════════════════════════════
                 Diseñar sistemas informáticos es equilibrar:
                 • RENDIMIENTO vs COSTE
                 • DISPONIBILIDAD vs COMPLEJIDAD
                 • FLEXIBILIDAD vs ESTANDARIZACIÓN
                 • CENTRALIZACIÓN vs AUTONOMÍA
                 
                 No hay soluciones perfectas, solo
                 compromisos informados basados en
                 requisitos de negocio y restricciones.
                 ═══════════════════════════════════════

11. REFERENCIAS BIBLIOGRÁFICAS Y NORMATIVAS

11.1. Arquitecturas de Sistemas

  1. Tanenbaum, Andrew S.; Van Steen, Maarten. "Distributed Systems: Principles and Paradigms". 3ª ed. Pearson, 2017. ISBN: 978-1543057386.
  2. Coulouris, George; Dollimore, Jean; Kindberg, Tim; Blair, Gordon. "Distributed Systems: Concepts and Design". 5ª ed. Addison-Wesley, 2011. ISBN: 978-0132143011.
  3. Fowler, Martin; Lewis, James. "Microservices: a definition of this new architectural term". martinfowler.com, 2014. Disponible en: https://martinfowler.com/articles/microservices.html
  4. Newman, Sam. "Building Microservices: Designing Fine-Grained Systems". 2ª ed. O'Reilly Media, 2021. ISBN: 978-1492034025.
  5. Richardson, Chris. "Microservices Patterns: With examples in Java". Manning Publications, 2018. ISBN: 978-1617294549.

11.2. Planificación y Capacity Planning

  1. Menascé, Daniel A.; Almeida, Virgilio A. F.; Dowdy, Lawrence W. "Performance by Design: Computer Capacity Planning by Example". Pearson, 2004. ISBN: 978-0130906731.
  2. Menascé, Daniel A.; Almeida, Virgilio A. F. "Scaling for E-Business: Technologies, Models, Performance, and Capacity Planning". Prentice Hall, 2000. ISBN: 978-0130863287.
  3. Jain, Raj. "The Art of Computer Systems Performance Analysis: Techniques for Experimental Design, Measurement, Simulation, and Modeling". Wiley, 1991. ISBN: 978-0471503361.
  4. Gunther, Neil J. "Guerrilla Capacity Planning: A Tactical Approach to Planning for Highly Scalable Applications and Services". Springer, 2007. ISBN: 978-3540261384.

11.3. Alta Disponibilidad y Escalabilidad

  1. Piedad, Floyd; Hawkins, Michael W. "High Availability: Design, Techniques and Processes". Prentice Hall, 2000. ISBN: 978-0130962881.
  2. Marcus, Evan; Stern, Hal. "Blueprints for High Availability". 2ª ed. Wiley, 2003. ISBN: 978-0471430261.
  3. Abbott, Martin L.; Fisher, Michael T. "The Art of Scalability: Scalable Web Architecture, Processes, and Organizations for the Modern Enterprise". 2ª ed. Addison-Wesley, 2015. ISBN: 978-0134032801.
  4. Allspaw, John; Robbins, Jesse. "Web Operations: Keeping the Data On Time". O'Reilly Media, 2010. ISBN: 978-1449377441.

11.4. Mainframes y Sistemas Multiusuario

  1. IBM Corporation. "IBM z16 Technical Introduction". IBM Redbooks, 2022. SG24-8538-00.
  2. Ebbers, Mike; O'Brien, W.; Ogden, B. "Introduction to the New Mainframe: z/OS Basics". IBM Redbooks, 2020. SG24-6366-03.
  3. Stair, Bill; Mao, Hailun. "Linux on IBM Z and LinuxONE". IBM Redbooks, 2023. SG24-8543-01.
  4. Hoskins, Jim; Frank, Roland; Pattinson, Alistair. "IBM z/OS V2R5 Communications Server TCP/IP Implementation". IBM Redbooks, 2023.
  5. Prasad, Karan; Seguias, Luis. "Virtualization Cookbook for IBM Z". IBM Redbooks, 2022. SG24-8147-04.

11.5. Sistemas Operativos y Multiprocesamiento

  1. Silberschatz, Abraham; Galvin, Peter B.; Gagne, Greg. "Operating System Concepts". 10ª ed. Wiley, 2018. ISBN: 978-1119320913.
  2. Tanenbaum, Andrew S.; Bos, Herbert. "Modern Operating Systems". 4ª ed. Pearson, 2014. ISBN: 978-013359162.
  3. Stallings, William. "Operating Systems: Internals and Design Principles". 9ª ed. Pearson, 2017. ISBN: 978-0134670959.
  4. Love, Robert. "Linux Kernel Development". 3ª ed. Addison-Wesley, 2010. ISBN: 978-0672329463.

11.6. Cloud Computing

  1. Armbrust, Michael et al. "A View of Cloud Computing". Communications of the ACM, Vol. 53, No. 4, 2010.
  2. Erl, Thomas; Puttini, Ricardo; Mahmood, Zaigham. "Cloud Computing: Concepts, Technology & Architecture". Prentice Hall, 2013. ISBN: 978-0133387520.
  3. Marinescu, Dan C. "Cloud Computing: Theory and Practice". 2ª ed. Morgan Kaufmann, 2017. ISBN: 978-0128128107.
  4. Jamsa, Kris. "Cloud Computing: SaaS, PaaS, IaaS, Virtualization, Business Models, Mobile, Security and More". Jones & Bartlett Learning, 2013. ISBN: 978-1449647070.

11.7. Rendimiento y Benchmarking

  1. Lilja, David J. "Measuring Computer Performance: A Practitioner's Guide". Cambridge University Press, 2000. ISBN: 978-0521641050.
  2. Hennessy, John L.; Patterson, David A. "Computer Architecture: A Quantitative Approach". 6ª ed. Morgan Kaufmann, 2017. ISBN: 978-0128119051.
  3. Transaction Processing Performance Council (TPC). "TPC Benchmark™ C Standard Specification". Version 5.11. Disponible en: http://www.tpc.org/
  4. Standard Performance Evaluation Corporation (SPEC). "SPEC CPU Benchmark Suite". Disponible en: https://www.spec.org/

11.8. Recursos Específicos del SAS

  1. Consejería de Salud y Consumo - Junta de Andalucía. "Plan de Transformación Digital del Sistema Sanitario Público de Andalucía 2022-2027". Sevilla, 2022.
  2. Servicio Andaluz de Salud. "Infraestructura Tecnológica SSPA". Documentación técnica interna, 2024.
  3. Decreto 208/2015, de 14 de julio, que regula la historia clínica digital del Sistema Sanitario Público de Andalucía. BOJA núm. 140, 21/07/2015.
  4. Real Decreto 4/2010, de 8 de enero, por el que se regula el Esquema Nacional de Interoperabilidad en el ámbito de la Administración Electrónica.
  5. Real Decreto 3/2010, de 8 de enero, por el que se regula el Esquema Nacional de Seguridad en el ámbito de la Administración Electrónica.

Tema 51 - Arquitecturas y Planificación de Sistemas Informáticos

Escalabilidad · Alta Disponibilidad · Sistemas Multiusuario · Mainframes · Capacity Planning

Preparación Oposiciones TFA-STI · Servicio Andaluz de Salud

Material actualizado octubre 2025 · Incluye IBM z16 (2022-), tendencias cloud/edge, datos SAS reales

"Planificar no es predecir el futuro, es prepararse para múltiples futuros posibles"

🏗️ De mainframes centralizados a arquitecturas híbridas cloud
Cada decisión arquitectónica impacta en millones de usuarios del SSPA

¡Mucho ánimo con tu preparación! 💪🏥💻

📊 Recuerda: No hay arquitectura perfecta, solo compromisos informados
🎯 La mejor arquitectura es la que satisface requisitos con recursos disponibles
💡 Planificar bien hoy evita problemas (y costes) mañana

Publicaciones relacionadas

EXAMEN DE TÉCNICO/A DE FUNCIÓN ADMINISTRATIVA, ADMINISTRACIÓN GENERAL / OEP 2025 / ACCESO LIBRE SERVICIO ANDALUZ DE SALUD

Esteban Castro

OPE 2025 TFA INF. Tema 27. La Estrategia de Salud Digital en Andalucía. Modelos de gobernanza de las tecnologías de la información y las comunicaciones (TIC) y su implantación en las Administraciones Públicas. Gobernanza y modelo organizativo TIC en el SSPA.

Esteban Castro

ENFERMERA. Tema 61. Atención a la familia. Atención familiar ante acontecimientos vitales complejos. Valoración e Intervención enfermera. Genograma.

Esteban Castro

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *