Tema 22 – Arquitecturas Básicas de los Sistemas Informáticos – SAS

📊 Tema 22

Arquitecturas Básicas de los Sistemas Informáticos

Técnico/a Especialista en Informática – Servicio Andaluz de Salud

💡 Palabras de tu preparador

Mira, este tema es de esos que te hacen decir «¡Por fin algo que entiendo de verdad!». Pero cuidado… porque en el examen no buscan que sepas lo obvio. Te van a preguntar por los matices, por esas decisiones arquitectónicas que parecen iguales pero que marcan la diferencia entre un sistema que aguanta y uno que se cae a las tres de la madrugada cuando hay un pico de urgencias.

Cuando hablamos de arquitecturas en el SAS no estamos jugando… cada decisión que tomemos sobre escalabilidad o alta disponibilidad puede significar que un médico acceda o no a la historia clínica de un paciente crítico. Piensa en Diraya funcionando 24/7/365 atendiendo a más de 100.000 profesionales sanitarios. ¿Cómo crees que lo hacemos? Pues con todo lo que vas a ver en este tema.

Examenes reales analizados: He revisado las preguntas de 2019, 2023 y 2025. Este tema es un clásico, siempre cae. Y lo que más preguntan es: alta disponibilidad (MTBF), escalabilidad, RAID, CPD TIER, arquitecturas multinivel y sistemas multiusuario. Así que vamos a fondo con eso.

📋 Índice de Contenidos

Contextualización y Marco Normativo
Conceptos Fundamentales de Sistemas Informáticos
Planificación de Sistemas Informáticos
Capacidad, Rendimiento y Métricas
Flexibilidad y Escalabilidad
Alta Disponibilidad
Sistemas Multiusuario
Arquitecturas Básicas
Evolución y Tendencias
Aplicación en el SAS
Casos Prácticos
Cuestionario de Evaluación (30 preguntas)
Mapa Conceptual
Conclusiones y Estrategia de Estudio
Referencias y Bibliografía

1. Contextualización y Marco Normativo

1.1. Relevancia en el Servicio Andaluz de Salud

Vamos a ponernos en contexto. El SAS no es una empresa cualquiera… estamos hablando del sistema sanitario público de Andalucía, que da servicio a más de 8,5 millones de personas. Los sistemas informáticos que soportan esta infraestructura no pueden fallar. Y cuando digo «no pueden», no es una exageración.

Imagínate la escena: son las 3 de la madrugada en el Hospital Virgen del Rocío. Llega una ambulancia con un paciente politraumatizado. El médico de urgencias necesita acceder a Diraya para ver si el paciente tiene alergias medicamentosas conocidas, si está anticoagulado, cuál es su grupo sanguíneo… Si Diraya no responde en ese momento, la vida del paciente puede estar en juego. Por eso, cada decisión arquitectónica que tomamos tiene que garantizar disponibilidad, rendimiento y escalabilidad.

            🎯 Datos clave del SAS que justifican las arquitecturas robustas:
            100.000+ profesionales sanitarios usando sistemas corporativos diariamente
8,5 millones de historias clínicas digitales en Diraya
1.500+ centros de salud y hospitales conectados
24/7/365 disponibilidad requerida para sistemas críticos
Millones de transacciones diarias en sistemas como Receta XXI
Tiempo de respuesta < 2 segundos para consultas clínicas en Diraya

        

1.2. Marco Normativo y Estratégico

Las decisiones arquitectónicas en el SAS no son caprichosas. Están enmarcadas en normativa y estrategias muy concretas:

Normativa / Estrategia	Impacto en Arquitecturas de Sistemas
Esquema Nacional de Seguridad (ENS) RD 311/2022	Obliga a implementar alta disponibilidad en sistemas de categoría ALTA. Define requisitos de continuidad del servicio, redundancia y recuperación ante desastres.
RGPD + LOPDGDD	Los datos de salud son categoría especial. Arquitecturas deben garantizar confidencialidad, integridad y disponibilidad con medidas técnicas robustas.
Plan de Transformación Digital 2022-2027	Migración progresiva a cloud híbrido, modernización de arquitecturas legacy, adopción de microservicios y contenedores.
Estrategia de Ciberseguridad SSPA	Arquitecturas deben incorporar seguridad by design, segmentación de red, zero trust, monitorización continua.
ITIL 4 / ISO 20000	Gestión de servicios TI con enfoque en valor. Arquitecturas orientadas a servicios (SOA), catálogo de servicios, SLAs bien definidos.
ISO 27001 / ISO 27799	Gestión de seguridad de la información en sanidad. Arquitecturas deben cumplir controles de seguridad específicos para datos de salud.

⚠️ Importante para el examen:

Pregunta típica: «¿Qué normativa obliga a implementar medidas de alta disponibilidad en sistemas que gestionan datos de salud de categoría ALTA en el sector público?»

Respuesta: El Esquema Nacional de Seguridad (ENS), específicamente en su dimensión de disponibilidad para sistemas de categoría ALTA, en combinación con RGPD (que exige disponibilidad de datos personales de salud).

1.3. Conexión con otros Temas del Temario

Este tema es el corazón técnico que conecta con muchos otros. No lo estudies aislado, porque en el examen te pueden liar mezclando conceptos:

Tema 11 (Gestión de Portfolio): Las arquitecturas son la implementación técnica del portfolio de soluciones digitales del SAS.
Tema 12 (ITIL): El diseño del servicio en ITIL define requisitos arquitectónicos (capacidad, disponibilidad, continuidad).
Tema 21 (Concepto de Sistema Informático): Base conceptual sobre la que se construyen las arquitecturas.
Tema 23 (Sistemas Operativos): Los SSOO multiusuario son la base de los sistemas corporativos del SAS.
Tema 33-34 (Bases de Datos): BBDD distribuidas, clústeres, RAC… todo arquitectura de datos.
Tema 35-36 (Seguridad / ENS): Las arquitecturas deben cumplir ENS, especialmente en disponibilidad.

2. Conceptos Fundamentales de Sistemas Informáticos

2.1. Definición y Componentes

Un sistema informático es un conjunto de elementos interrelacionados (hardware, software, datos, procedimientos y personas) que trabajan coordinadamente para procesar información y proporcionar servicios de computación.

            📦 Componentes de un Sistema Informático (Jerarquía de Niveles):
            Nivel 0 – Hardware Físico: CPU, memoria, almacenamiento, red, periféricos
Nivel 1 – Firmware y BIOS/UEFI: Software embebido en el hardware
Nivel 2 – Sistema Operativo: Capa de abstracción que gestiona recursos (Linux, Windows Server)
Nivel 3 – Middleware y Servicios: BBDD, servidores de aplicaciones, buses de servicios (Oracle, JBoss, ESB)
Nivel 4 – Aplicaciones: Software que proporciona funcionalidad al usuario final (Diraya, Receta XXI)
Nivel 5 – Usuarios y Procesos: Profesionales sanitarios que interactúan con el sistema

        

En el examen de 2025 (Turno Libre) preguntaron literalmente esto:

Pregunta Real Examen 2025

¿Cuál de las siguientes afirmaciones sobre los sistemas informáticos y su jerarquía de niveles es correcta?

A) Los niveles más bajos en la jerarquía se ocupan únicamente del almacenamiento de datos.

B) En la jerarquía de niveles, el sistema operativo actúa como una capa de abstracción entre el hardware y el software de aplicación. ✓

C) En la jerarquía de sistemas informáticos, el software de aplicación interactúa directamente con el hardware.

D) Los sistemas informáticos siempre siguen una jerarquía estricta, sin excepción.

✓ Respuesta Correcta: B

Por qué B es correcta: El sistema operativo es precisamente esa capa de abstracción que permite que las aplicaciones no tengan que «hablar directamente» con el hardware. En el SAS, esto significa que Diraya (aplicación) no gestiona directamente la RAM o los discos… lo hace el SO (Linux/Windows Server).

Por qué las demás fallan:

A) Falso: Los niveles bajos (hardware) hacen mucho más que almacenar: procesan, transmiten, controlan…
C) Falso: Las aplicaciones NO interactúan directamente con el hardware. Usan APIs del SO.
D) Falso: Hay excepciones: firmware, drivers que «saltan» capas, virtualización que «aplana» jerarquías…

2.2. Clasificación de Sistemas Informáticos

En el SAS conviven diferentes tipos de sistemas. No todo es un mainframe ni todo es un PC. Cada tipo tiene su propósito:

Tipo de Sistema	Características	Ejemplos en el SAS
Sistemas Mainframe	Alta capacidad de procesamiento, miles de usuarios concurrentes, altísima disponibilidad (99.999%), arquitectura propietaria	Históricamente usados para Nómina. En desuso progresivo.
Servidores de Rango Medio (Midrange)	Sistemas departamentales, cientos de usuarios, disponibilidad 99.9%, más flexibles que mainframes	Servidores AIX (IBM Power) para aplicaciones corporativas legacy
Servidores x86/x64	Arquitectura abierta, escalabilidad horizontal, virtualizables, relación coste-beneficio óptima	La INMENSA mayoría de sistemas del SAS: Diraya, Receta XXI, BPS, todos corren en servidores Dell/HPE x86 con VMware
Sistemas en Nube (Cloud)	IaaS/PaaS/SaaS, elasticidad, pago por uso, alta disponibilidad geográfica	Migración progresiva: ClicSalud+ (Azure), Office 365, soluciones híbridas con AWS/Azure
Edge Computing / IoT	Procesamiento en el borde, baja latencia, dispositivos médicos conectados	Dispositivos IoMT (Internet of Medical Things), monitorización remota de pacientes

🎓 Truco para el examen:

Si te preguntan por «unidades centrales multiusuario», están hablando de servidores que dan servicio a múltiples usuarios simultáneamente. En el SAS, el 90% son servidores x86/x64 virtualizados corriendo Linux (RHEL/CentOS) o Windows Server. Los mainframes son cosa del pasado (aunque algunos hospitales antiguos aún tienen alguno funcionando para sistemas legacy de contabilidad o nómina).

3. Planificación de los Sistemas Informáticos

3.1. Concepto y Objetivos

Planificar un sistema informático no es sentarse a comprar servidores al tuntún. Es un proceso metodológico que debe responder a objetivos de negocio (o asistenciales, en nuestro caso). En el SAS, la planificación de sistemas se rige por el Plan de Sistemas de Información de Andalucía (PSIA) y por las directrices de la Dirección General de Sistemas de Información y Comunicaciones (DGSIC).

            🎯 Objetivos de la Planificación de Sistemas Informáticos:
            Alinear TI con la estrategia asistencial: Los sistemas deben soportar los procesos asistenciales integrados (PAIs), la telemedicina, la historia clínica compartida…
Optimizar recursos: Máximo aprovechamiento de infraestructura, evitar redundancias innecesarias, consolidación de CPDs
Garantizar continuidad del servicio: Planificar redundancias, backups, planes de contingencia
Escalabilidad futura: Prever crecimiento de usuarios, datos, transacciones
Cumplimiento normativo: ENS, RGPD, ISO 27001, directivas europeas
Gestión del ciclo de vida: Renovación tecnológica planificada, evitar obsolescencia

        

3.2. Metodologías de Planificación

No inventamos la rueda. Hay metodologías probadas que usamos (o deberíamos usar) en el SAS:

Metodología	Aplicación en el SAS
MÉTRICA v3	Metodología oficial de la Junta de Andalucía para desarrollo de sistemas. Define fases de planificación, análisis y diseño arquitectónico.
COBIT 2019	Marco de gobierno TI. Ayuda a definir objetivos de TI alineados con negocio, gestión de riesgos, inversiones en infraestructura.
TOGAF	Framework de arquitectura empresarial. Define dominios: negocio, aplicaciones, datos, tecnología. Útil para planificación macro de la Red Corporativa SAS.
ITIL 4 – Strategy Management for IT Services	Práctica de ITIL para gestión estratégica de servicios TI. Define Portfolio de Servicios, que luego se traduce en arquitecturas.

3.3. Fases de la Planificación

Siguiendo MÉTRICA v3 (que es LO que debes conocer para la oposición), la planificación arquitectónica se encuadra en:

PSI – Planificación de Sistemas de Información: Estudio de la situación actual, identificación de necesidades, definición del modelo de información y del sistema de información objetivo.
EVS – Estudio de Viabilidad del Sistema: Análisis coste-beneficio, evaluación de riesgos, valoración de alternativas arquitectónicas.
ASI – Análisis del Sistema de Información: Definición de requisitos funcionales y NO funcionales (ahí entran rendimiento, disponibilidad, escalabilidad).
DSI – Diseño del Sistema de Información: AQUÍ se define la arquitectura detallada: capas, componentes, despliegue, tecnologías, dimensionamiento.
CSI – Construcción del Sistema de Información: Implementación física de la arquitectura diseñada.

📌 Pregunta real de examen (2025 – Técnico Titulado Medio):

«¿En qué fase del ciclo de vida se define la arquitectura técnica del sistema, incluyendo selección de tecnologías y diseño de componentes?»

Respuesta correcta: C) Diseño del sistema

En la fase de Diseño del Sistema (DSI en MÉTRICA v3) es donde se establecen la arquitectura general del sistema, se seleccionan las tecnologías, se definen los módulos, las interfaces y se detallan los componentes individuales antes de la implementación real.

4. Capacidad, Rendimiento y Métricas

4.1. Gestión de la Capacidad

La capacidad es la habilidad de un sistema para satisfacer las cargas de trabajo actuales y futuras. En ITIL 4, la Capacity and Performance Management es una práctica clave que debemos dominar.

Imagina que eres el responsable de infraestructura del Hospital Virgen del Rocío. Tienes que dimensionar los servidores que van a alojar Diraya. ¿Cuánta CPU necesitas? ¿Cuánta RAM? ¿Cuánto almacenamiento? Si te quedas corto, el sistema irá lento y los médicos se quejarán. Si te pasas, estarás despilfarrando dinero público en servidores infrautilizados.

            🔍 Dimensiones de la Capacidad:
            Capacidad de procesamiento (CPU): Medida en cores, GHz, MIPS, transacciones/segundo
Capacidad de memoria (RAM): GB/TB disponibles, latencia, ancho de banda
Capacidad de almacenamiento: TB/PB, IOPS (operaciones E/S por segundo), throughput
Capacidad de red: Gbps de ancho de banda, latencia, paquetes/segundo
Capacidad de usuarios concurrentes: Número de sesiones simultáneas que el sistema puede manejar sin degradación

        

4.2. Rendimiento

El rendimiento mide qué tan eficientemente un sistema utiliza los recursos disponibles para cumplir con los requisitos. No es lo mismo «tener capacidad» que «tener buen rendimiento».

Ejemplo del SAS: Puedes tener un servidor con 128 GB de RAM (mucha capacidad), pero si la aplicación está mal programada y tiene fugas de memoria, el rendimiento será pésimo aunque sobren recursos.

Métrica de Rendimiento	Definición	Objetivo en SAS
Tiempo de Respuesta	Tiempo entre que el usuario hace una petición y recibe respuesta	< 2 segundos para consultas en Diraya
Throughput	Cantidad de trabajo procesado por unidad de tiempo (transacciones/seg, consultas/seg)	Diraya: > 1.000 transacciones/segundo en horas pico
Latencia	Retardo mínimo para procesar una petición (componente de tiempo de respuesta)	Red Corporativa SAS: < 10 ms entre centros
Utilización de Recursos	% de uso de CPU, RAM, disco, red	CPU < 70% en media, picos < 85%
Tasa de Error	% de peticiones que fallan	< 0.1% en sistemas críticos

4.3. Métricas de Capacidad y Dimensionamiento

Para dimensionar un sistema, usamos técnicas de capacity planning:

Análisis de Tendencias: Revisar históricos de uso, proyectar crecimiento lineal/exponencial
Modelado Analítico: Teoría de colas, leyes operacionales (Ley de Little, Ley de Utilización)
Simulación: Modelos de simulación para predecir comportamiento bajo diferentes cargas
Benchmarking: Pruebas de carga reales en entornos de pre-producción

📋 Caso Práctico: Dimensionamiento de Diraya para un Nuevo Hospital

Situación: Se va a abrir el nuevo Hospital de Alta Resolución de Écija. Necesitas dimensionar los servidores para Diraya.

Datos:

150 profesionales sanitarios trabajando simultáneamente en hora pico
Cada profesional realiza en media 30 consultas/hora a Diraya
Cada consulta requiere: 2 consultas SQL, 150 ms de CPU, 5 MB de transferencia de red
La base de datos ya está dimensionada y soporta 5.000 consultas/seg sin degradación

Pregunta: ¿Cuántos cores de CPU necesitas en el servidor de aplicaciones (asumiendo 1 core = 100 ms de procesamiento disponible por segundo)?

Resolución:

Consultas totales en hora pico: 150 profesionales × 30 consultas/hora = 4.500 consultas/hora = 1.25 consultas/segundo
CPU necesaria: 1.25 consultas/seg × 150 ms/consulta = 187.5 ms de CPU/segundo
Cores necesarios: 187.5 ms / 100 ms = 1.875 cores
Dimensionamiento real: 2 cores con margen de seguridad (50% de buffer) → 3 cores mínimo, recomendado 4 cores

Observación: En la realidad, dimensionarías con margen mucho mayor (×3 o ×4), porque hay picos impredecibles, tareas de mantenimiento, crecimiento futuro, etc.

5. Flexibilidad y Escalabilidad

5.1. Flexibilidad

La flexibilidad es la capacidad de un sistema para adaptarse a cambios en los requisitos, tecnologías o condiciones de operación sin necesidad de grandes rediseños.

Un sistema flexible en el SAS es aquel que puede:

Integrar nuevos módulos o aplicaciones sin afectar los existentes
Migrar a nuevas tecnologías de forma gradual (ej: pasar de Oracle a PostgreSQL en ciertos módulos)
Adaptarse a cambios normativos (ej: nueva funcionalidad en receta electrónica por cambio legislativo)
Soportar múltiples canales (web, móvil, kioscos, APIs)

            🔧 Técnicas para Lograr Flexibilidad:
            Arquitecturas en capas: Separación presentación / lógica / datos permite cambiar una sin afectar las demás
Microservicios: Servicios independientes, cada uno con su tecnología, escalables y desplegables por separado
APIs RESTful: Interfaces bien definidas permiten cambiar implementación sin romper integraciones
Virtualización y contenedores: Independencia del hardware, portabilidad entre entornos
Configuración externalizada: Cambios de comportamiento sin recompilar código

        

5.2. Escalabilidad

La escalabilidad es la capacidad de un sistema para mantener o mejorar su rendimiento a medida que aumenta la carga de trabajo (más usuarios, más datos, más transacciones).

Esta es una pregunta MUY típica de examen. De hecho, cayó en 2023 literal:

Pregunta Real Examen 2023

¿Qué característica, ligada al diseño de un sistema, se define como la capacidad de adaptación y respuesta de un sistema con respecto al rendimiento del mismo a medida que aumenta de forma significativa el número de usuarios?

A) Flexibilidad

B) Alta disponibilidad

C) Escalabilidad ✓

D) Redundancia

✓ Respuesta Correcta: C) Escalabilidad

Definición formal de escalabilidad: Capacidad de un sistema para mantener o mejorar su nivel de rendimiento cuando aumenta la carga (usuarios, transacciones, datos).

Por qué las demás fallan:

A) Flexibilidad: Se refiere a adaptarse a CAMBIOS (nuevos requisitos, tecnologías), no a CRECER en carga.
B) Alta disponibilidad: Se refiere a MINIMIZAR el tiempo de caída, no a soportar más usuarios.
D) Redundancia: Es una TÉCNICA para lograr alta disponibilidad (duplicar componentes), no la característica de soportar más carga.

5.3. Tipos de Escalabilidad

Tipo	Descripción	Ventajas	Inconvenientes	Ejemplo en SAS
Escalabilidad Vertical (Scale Up)	Aumentar la potencia de un servidor individual (más CPU, RAM, disco)	– Simplicidad – No requiere cambios de arquitectura – Menor latencia	– Límite físico (no puedes poner CPU infinitas) – Más caro – Punto único de fallo	Aumentar RAM de 64GB a 256GB en servidor de BBDD Oracle de Diraya
Escalabilidad Horizontal (Scale Out)	Añadir más servidores y distribuir la carga entre ellos	– Escalabilidad casi ilimitada – Relación coste-beneficio mejor – Mayor disponibilidad	– Complejidad arquitectónica – Requiere balanceo de carga – Gestión de estado distribuido	Añadir servidores de aplicación de Diraya en un clúster con balanceador

🎯 Tendencia actual en el SAS:

El SAS está migrando de arquitecturas verticales (un gran servidor para cada aplicación) a arquitecturas horizontales basadas en clústeres de servidores x86 con virtualización y contenedores. Esto permite:

Mejor aprovechamiento de recursos (consolidación)
Escalabilidad dinámica (añadir nodos al clúster)
Integración con cloud híbrido (AWS/Azure)
Uso de orquestadores como Kubernetes para auto-escalado

5.4. Escalabilidad en Arquitecturas de Aplicación

No solo escalamos hardware… también las aplicaciones deben diseñarse para escalar. En el examen de 2025 (Técnico Titulado Medio) preguntaron sobre esto:

Pregunta Real Examen 2025 – TTM

En el contexto de una arquitectura de sistemas multicanal que debe gestionar eficientemente grandes volúmenes de usuarios accediendo simultáneamente desde múltiples dispositivos, ¿qué enfoque arquitectónico proporciona una mayor agilidad y escalabilidad?

A) Arquitectura monolítica con implementación de caché distribuido para optimización de rendimiento

B) Arquitectura de microservicios combinada con una arquitectura basada en eventos (EDA) para una mejor coordinación y escalabilidad ✓

C) Arquitectura tradicional cliente-servidor utilizando procesamiento centralizado para simplificar la gestión de cargas

D) Sistema basado en una base de datos distribuida con sincronización eventual para manejo de datos en tiempo real

✓ Respuesta Correcta: B

Por qué B es correcta:

Los microservicios permiten escalar cada funcionalidad de forma independiente. Si el módulo de citas de ClicSalud+ tiene mucha carga, escalo solo ese microservicio, no toda la aplicación.

La arquitectura basada en eventos (EDA – Event-Driven Architecture) desacopla componentes mediante mensajes asíncronos, lo que mejora la escalabilidad porque los servicios no tienen que esperar respuestas síncronas.

Por qué las demás fallan:

A) Monolítica: Aunque añadas caché, el monolito escala vertical (todo o nada), no horizontal.
C) Cliente-servidor centralizado: El servidor centralizado es un cuello de botella. No escala bien.
D) BBDD distribuida: Soluciona escalabilidad de datos, pero no de la lógica de aplicación.

6. Alta Disponibilidad

6.1. Concepto y Necesidad en el SAS

La Alta Disponibilidad (HA – High Availability) es la característica de un sistema de permanecer operativo y accesible durante el mayor tiempo posible, minimizando los periodos de inactividad planificados y no planificados.

En el SAS, la alta disponibilidad no es un lujo… es una obligación legal y ética. El ENS (Esquema Nacional de Seguridad) exige para sistemas de categoría ALTA (como Diraya) medidas específicas de disponibilidad. Y desde el punto de vista ético, un sistema sanitario caído puede poner en riesgo vidas humanas.

⚠️ Consecuencias de la NO disponibilidad en sanidad:

Imposibilidad de acceder a historias clínicas en urgencias
No poder dispensar medicamentos (Receta XXI caído)
Cirugías que no pueden realizarse por falta de acceso a estudios preoperatorios
Riesgo de errores médicos por falta de información del paciente
Incumplimiento de SLAs con impacto reputacional y legal

6.2. Métricas de Alta Disponibilidad

La disponibilidad se mide como un porcentaje del tiempo que el sistema está operativo:

Disponibilidad (%) = (Tiempo Total – Tiempo de Inactividad) / Tiempo Total × 100

Disponibilidad	Nomenclatura	Downtime Anual	Downtime Mensual	Aplicación en SAS
90%	«Un nueve»	36.5 días	3 días	❌ Inaceptable para cualquier sistema corporativo
99%	«Dos nueves»	3.65 días	7.2 horas	⚠️ Sistemas no críticos, aplicaciones internas de soporte
99.9%	«Tres nueves»	8.76 horas	43 minutos	✓ Sistemas estándar del SAS (portales informativos, intranets)
99.95%	«Tres nueves y medio»	4.38 horas	21 minutos	✓✓ Sistemas corporativos importantes (JIRA, Confluence)
99.99%	«Cuatro nueves»	52.56 minutos	4.3 minutos	✓✓✓ Sistemas críticos del SAS (Diraya, Receta XXI, BPS)
99.999%	«Cinco nueves»	5.26 minutos	26 segundos	🏆 Objetivo para Diraya y sistemas de misión crítica

6.3. Pregunta Típica de Examen sobre Métricas

Esta pregunta es un CLÁSICO. Cayó en 2023:

Pregunta Real Examen 2023

¿Qué métrica se utiliza para medir la alta disponibilidad de un sistema de información?

A) Tiempo medio entre fallos (MTBF) ✓

B) Latencia

C) Tiempo de respuesta

D) Consumo de CPU

✓ Respuesta Correcta: A) MTBF

Métricas clave de disponibilidad:

MTBF (Mean Time Between Failures): Tiempo medio entre fallos. A mayor MTBF, más disponible es el sistema. Ejemplo: MTBF de 10.000 horas significa que, en promedio, el sistema falla cada 10.000 horas de operación.
MTTR (Mean Time To Repair): Tiempo medio de reparación. Tiempo que se tarda en restaurar el servicio tras un fallo. A menor MTTR, mejor (recuperación más rápida).
MTTF (Mean Time To Failure): Tiempo medio hasta el fallo. Similar a MTBF pero para componentes no reparables.

Disponibilidad = MTBF / (MTBF + MTTR)

Ejemplo: Si un servidor tiene MTBF = 8.760 horas (1 año) y MTTR = 2 horas:

Disponibilidad = 8.760 / (8.760 + 2) = 8.760 / 8.762 = 99.977% (casi cuatro nueves)

Y también cayó en 2025 (Turno Libre):

Pregunta Real Examen 2025

¿Qué característica define mejor un sistema con alta disponibilidad?

A) Puede dar acceso a un alto número de usuarios simultáneamente

B) Permite compartir un alto número de recursos

C) Permite ejecutar un alto número de tareas en paralelo por cada CPU

D) Garantiza un tiempo mínimo de inactividad y una recuperación rápida ✓

✓ Respuesta Correcta: D

Por qué D es correcta: La definición EXACTA de alta disponibilidad es garantizar que el sistema esté operativo el máximo tiempo posible, con el mínimo tiempo de inactividad (downtime). Y cuando hay un fallo, la recuperación debe ser rápida (bajo MTTR).

Por qué las demás NO definen HA:

A) Alto número de usuarios simultáneos: Eso es ESCALABILIDAD o CAPACIDAD, no disponibilidad.
B) Compartir recursos: Eso es característica de sistemas multiusuario o virtualización, no disponibilidad.
C) Tareas en paralelo: Eso es PARALELISMO o CONCURRENCIA, no disponibilidad.

6.4. Técnicas para Lograr Alta Disponibilidad

6.4.1. Redundancia

La técnica fundamental para HA es la redundancia: tener componentes duplicados (o triplicados) para que si uno falla, otro tome el relevo automáticamente.

Tipo de Redundancia	Descripción	Ejemplo en SAS
Redundancia Activa-Pasiva (Active-Standby)	Un componente principal (activo) y uno o más de respaldo (standby) que solo entran en servicio si el principal falla	BBDD Oracle de Diraya con Oracle Data Guard: BBDD principal en CPD de Sevilla, BBDD standby en CPD de Granada. Si cae Sevilla, Granada toma el relevo.
Redundancia Activa-Activa (Active-Active)	Todos los componentes están activos simultáneamente, compartiendo la carga	Clúster de servidores de aplicación de Diraya con balanceador F5. Los 4 servidores atienden peticiones simultáneamente. Si cae uno, los otros 3 absorben su carga.
Redundancia N+1	N componentes necesarios para la carga + 1 de respaldo	Si necesitas 3 servidores para soportar la carga, tienes 4 (3+1). Si cae uno, quedan 3 operativos.
Redundancia N+2	N componentes necesarios + 2 de respaldo	Sistemas muy críticos donde quieres soportar hasta 2 fallos simultáneos.
Redundancia 2N	Duplicar completamente la infraestructura	Tener dos CPDs completos, cada uno con capacidad para soportar el 100% de la carga.
Redundancia 2N+1	Dos infraestructuras completas + 1 componente adicional de respaldo	El nivel más alto de redundancia. Usado en CPD TIER IV (ver siguiente pregunta).

6.4.2. CPD TIER y Configuración 2N+1

Los Centros de Proceso de Datos se clasifican según estándares TIER (del Uptime Institute) que definen niveles de disponibilidad:

TIER	Disponibilidad	Downtime Anual	Características
TIER I	99.671%	28.8 horas	Básico. Sin redundancia. Parada para mantenimiento.
TIER II	99.741%	22 horas	Componentes redundantes (N+1), pero camino único de distribución.
TIER III	99.982%	1.6 horas	Mantenimiento sin parada. Múltiples caminos de distribución, pero solo uno activo.
TIER IV	99.995%	26 minutos	Tolerante a fallos. Redundancia 2N+1. Múltiples caminos activos. Fallo de cualquier componente no afecta servicio.

Pregunta real de examen 2025 (Técnico Titulado Medio):

Pregunta Real Examen 2025 – TTM

¿Qué configuración de redundancia se asocia típicamente con un Centro de Proceso de Datos (CPD) clasificado como TIER IV?

A) N+1

B) 2N+1 ✓

C) N

D) 2N

✓ Respuesta Correcta: B) 2N+1

TIER IV es el nivel más alto de disponibilidad en CPDs. Se caracteriza por:

Redundancia 2N+1: Significa tener el doble de capacidad necesaria (2N) más un componente adicional de respaldo (+1). Esto garantiza que puedes perder una ruta COMPLETA de componentes y aún así tener respaldo.
Tolerancia a fallos: Cualquier componente puede fallar sin afectar la operación.
Mantenimiento concurrente: Puedes hacer mantenimiento sin parar el servicio.

Ejemplo práctico en SAS: El CPD principal del SAS en Sevilla debería ser (idealmente) TIER III o IV para Diraya. Esto significa que si falla un sistema de alimentación eléctrica, hay otro que lo respalda. Si falla un sistema de refrigeración, hay otro. Si falla una línea de red, hay otra. Todo duplicado (2N) más respaldo adicional (+1).

6.4.3. Clústeres y Balanceo de Carga

Un clúster es un conjunto de servidores que trabajan juntos para proporcionar un servicio único, aparentando ser un solo sistema ante el usuario.

            🔧 Tipos de Clústeres para Alta Disponibilidad:
            Clúster de Alta Disponibilidad (HA Cluster): Si un nodo falla, otro toma su lugar. Ejemplo: cluster de Pacemaker + Corosync para servicios críticos en Linux.
Clúster de Balanceo de Carga (Load Balancing Cluster): Distribuye peticiones entre múltiples nodos para mejorar rendimiento y disponibilidad. Ejemplo: balanceador F5 BIG-IP delante de servidores de aplicación de Diraya.
Clúster de Base de Datos (DB Cluster): Múltiples instancias de BBDD compartiendo almacenamiento. Ejemplo: Oracle RAC (Real Application Clusters) para Diraya.

        

Pregunta real relacionada en examen 2025 (Técnico Titulado Medio):

Pregunta Real Examen 2025 – TTM

El administrador de bases de datos necesita simplificar la gestión del almacenamiento, mejorar el rendimiento y garantizar la alta disponibilidad mediante la distribución automática de datos entre varios discos en Oracle. ¿Qué tecnología nativa de Oracle debería utilizar?

A) Oracle Data Pump

B) Oracle RAC

C) Oracle ASM ✓

D) Oracle Data Guard

✓ Respuesta Correcta: C) Oracle ASM

Oracle ASM (Automatic Storage Management) es un gestor de volúmenes y sistema de archivos específico para bases de datos Oracle. Proporciona:

Distribución automática de datos entre discos (striping) para mejorar rendimiento
Redundancia mediante mirroring para alta disponibilidad
Gestión simplificada del almacenamiento sin necesidad de LVM o sistemas de archivos tradicionales

Por qué las demás fallan:

A) Oracle Data Pump: Herramienta para importar/exportar datos, no para gestión de almacenamiento.
B) Oracle RAC: Clúster de instancias Oracle para HA y escalabilidad, pero no gestiona directamente el almacenamiento de discos.
D) Oracle Data Guard: Solución de recuperación ante desastres mediante réplica de BBDD, no gestión de almacenamiento.

En el SAS: Diraya usa Oracle RAC + Oracle ASM. RAC proporciona clúster de instancias (HA a nivel de aplicación), mientras que ASM gestiona el almacenamiento subyacente con redundancia.

6.4.4. RAID para Alta Disponibilidad de Almacenamiento

RAID (Redundant Array of Independent Disks) es una tecnología que combina múltiples discos físicos en una unidad lógica para mejorar rendimiento y/o disponibilidad.

RAID	Descripción	Discos Necesarios	Tolerancia a Fallos	Rendimiento	Uso en SAS
RAID 0	Striping sin paridad. Datos distribuidos entre discos.	2+	❌ Ninguna. Si falla un disco, se pierde todo.	⚡⚡⚡ Excelente lectura/escritura	❌ NO se usa en producción (demasiado riesgo)
RAID 1	Mirroring. Duplicación exacta de datos en 2+ discos.	2+	✓ Tolera fallo de N-1 discos	⚡⚡ Buena lectura, escritura normal	✓ Para discos de SO, logs críticos
RAID 5	Striping con paridad distribuida. Paridad se distribuye entre todos los discos.	3+	✓ Tolera fallo de 1 disco	⚡⚡ Buena lectura, escritura penalizada	✓ Uso común para almacenamiento de aplicaciones
RAID 6	Striping con doble paridad distribuida. 2 bloques de paridad.	4+	✓✓ Tolera fallo de 2 discos cualesquiera	⚡⚡ Buena lectura, escritura más penalizada que RAID 5	✓✓ Ideal para almacenamiento crítico de BBDD
RAID 10	RAID 1+0. Combinación de mirroring y striping.	4+ (par)	✓✓ Tolera fallo de 1 disco por cada par	⚡⚡⚡ Excelente lectura/escritura	✓✓✓ Óptimo para BBDD de alto rendimiento (Diraya)

Pregunta real de examen 2025 (Técnico Titulado Medio):

Pregunta Real Examen 2025 – TTM

¿En qué consiste la técnica de almacenamiento de información denominada RAID 6?

A) En que la información se distribuye entre seis o más discos, actuando dos de ellos como bit de paridad de modo que el sistema es tolerante al fallo

B) En que la información se distribuye entre tres o más discos, actuando uno de ellos como bit de paridad de modo que el sistema es tolerante al fallo de cualquier disco

C) En que la información se distribuye entre cuatro o más discos. La capacidad utilizable es aproximadamente la mitad de la capacidad total instalada, ya que se duplica la información para ofrecer redundancia

D) En que la información se distribuye entre cuatro o más discos, actuando dos de ellos como bit de paridad de modo que el sistema es tolerante al fallo de cualesquiera dos discos ✓

✓ Respuesta Correcta: D

RAID 6 se caracteriza por:

Striping con doble paridad distribuida: Los datos y DOS bloques de paridad se distribuyen entre todos los discos
Mínimo 4 discos: Necesitas al menos 4 discos (2 para datos, 2 para paridad doble)
Tolerancia a 2 fallos: Puedes perder CUALQUIER 2 discos simultáneamente y seguir operativo
Capacidad utilizable: (N-2) × capacidad_disco, donde N = número total de discos

Ejemplo práctico: Tienes 6 discos de 2 TB cada uno (12 TB totales). Con RAID 6, capacidad utilizable = (6-2) × 2 TB = 8 TB (4 TB se «pierden» en paridad).

Por qué las demás fallan:

A) Falsa: El «6» de RAID 6 NO significa 6 discos. Significa doble paridad.
B) Falsa: Eso sería RAID 5 (un solo bloque de paridad, tolera 1 fallo).
C) Falsa: Eso sería RAID 1 o RAID 10 (mirroring completo).

En el SAS: RAID 6 se usa en cabinas de almacenamiento SAN para bases de datos críticas. Si tienes una cabina con 24 discos, un RAID 6 te protege mejor que RAID 5 porque tolera 2 fallos (importante durante el tiempo de rebuild, que con discos grandes puede tardar horas y aumenta el riesgo de un segundo fallo).

6.4.5. Virtualización y Alta Disponibilidad

La virtualización es un aliado clave para HA. Con hipervisores como VMware vSphere (usado en el SAS), puedes implementar funcionalidades avanzadas:

vMotion: Migrar una VM en caliente (sin parada) de un host a otro. Útil para mantenimiento sin downtime.
HA (High Availability): Si un host físico falla, las VMs se reinician automáticamente en otros hosts del clúster.
DRS (Distributed Resource Scheduler): Balancea automáticamente la carga entre hosts del clúster.
Fault Tolerance: Réplica continua de una VM en otro host. Si el host principal falla, la VM secundaria toma el relevo sin pérdida de conexiones.

Pregunta relacionada del examen 2025 (Técnico Titulado Medio):

Pregunta Real Examen 2025 – TTM

El Hospital Universitario del Sur cuenta con un sistema de virtualización basado en hiperconvergencia. ¿Qué significa dicha tecnología?

A) Se dispone de una arquitectura tradicional en capas, con el almacenamiento, red y servidores de manera independiente

B) Se unifica computación, almacenamiento, red y software en un único sistema para minimizar la complejidad de la arquitectura ✓

C) En realidad, la hiperconvergencia hace referencia a implantación de servidores físicos no virtualizados

D) La hiperconvergencia solo utiliza virtualización por contenedores

✓ Respuesta Correcta: B

Hiperconvergencia (HCI – Hyper-Converged Infrastructure) unifica en un único «appliance» o nodo:

Computación: Hipervisor para ejecutar VMs
Almacenamiento: SAN virtualizado distribuido entre nodos
Red: Virtual networking (SDN)
Software de gestión: Consola única para todo

Ventajas de HCI en el SAS:

Simplicidad: no necesitas cabinas SAN separadas, switches FC, gestión compleja
Escalabilidad: añades nodos al clúster y automáticamente aumentas CPU, RAM y almacenamiento
Alta disponibilidad: si un nodo falla, las VMs migran a otros nodos
Reducción de costes: menos hardware especializado, menos consumo energético

Productos HCI en el SAS: Nutanix, VMware vSAN, Cisco HyperFlex. Cada vez más hospitales del SAS están migrando a HCI para centros de datos locales.

7. Sistemas Multiusuario

7.1. Concepto y Características

Un sistema multiusuario es aquel que permite que múltiples usuarios accedan simultáneamente a los recursos de un sistema informático central, compartiendo CPU, memoria, almacenamiento y periféricos.

En el SAS, TODOS los sistemas corporativos son multiusuario. Diraya no es una aplicación de un solo usuario… son MILES de médicos, enfermeras, administrativos accediendo simultáneamente.

            📊 Características de Sistemas Multiusuario:
            Time-sharing: La CPU se reparte entre usuarios mediante quantum de tiempo (multitarea preemptiva)
Gestión de procesos: El SO gestiona procesos de múltiples usuarios, con aislamiento entre ellos
Gestión de memoria: Memoria virtual, paginación, swapping para aislar espacios de memoria de usuarios
Control de acceso: Permisos, usuarios, grupos, ACLs para proteger recursos
Colas de E/S: Gestión de acceso a discos, red, impresoras entre múltiples usuarios
Contabilidad y auditoría: Registro de quién hace qué y cuándo (crítico en sanidad por RGPD)

        

7.2. Evolución de Sistemas Multiusuario

Era	Tecnología	Características	Ejemplo
1960-1980	Mainframes con terminales tontos	Un mainframe central, terminales sin capacidad de procesamiento, acceso por línea de comandos	IBM System/360, DEC VAX con terminales VT-100
1980-2000	Servidores Unix/Linux + PCs clientes	Cliente-servidor, terminales con capacidad de procesamiento, interfaces gráficas (X Window)	Servidores Sun Solaris / AIX con estaciones de trabajo Unix
2000-2010	Servidores x86 + Terminales Windows	Windows Server + Citrix / Terminal Services, aplicaciones web	Servidores Windows Server 2003/2008, Citrix XenApp para publicación de aplicaciones
2010-Actualidad	Cloud + Virtualización + Contenedores	Multi-tenant cloud, microservicios, acceso web/móvil, VDI (Virtual Desktop Infrastructure)	VMware Horizon para VDI, Kubernetes para microservicios, aplicaciones SaaS (Office 365, ClicSalud+)

7.3. Sistemas Multiusuario en el SAS

🏥 Caso Real: Arquitectura Multiusuario de Diraya

Contexto: Diraya debe soportar acceso simultáneo de más de 100.000 profesionales sanitarios en toda Andalucía. Picos de carga entre 9:00-10:00 y 18:00-19:00.

Arquitectura implementada:

Capa de acceso: Thin clients (LETSAS – Linux embebido en terminales SAS) + PCs Windows + tablets/móviles
Capa de presentación web: Servidores Apache/Tomcat en clúster (balanceador F5)
Capa de lógica de negocio: Servidores JBoss/WebLogic con aplicaciones J2EE
Capa de datos: Clúster Oracle RAC de 4 nodos con Oracle ASM (almacenamiento compartido en cabina SAN)

Gestión de sesiones concurrentes:

Cada usuario autenticado tiene una sesión en el servidor de aplicaciones
El balanceador distribuye nuevas sesiones entre servidores mediante algoritmo round-robin o least connections
Las sesiones se mantienen con «sticky sessions» (afinidad de sesión) o con replicación de sesiones entre nodos
Timeout de inactividad: 15 minutos (por seguridad RGPD)

8. Arquitecturas Básicas de Sistemas Informáticos

8.1. Arquitectura en Capas (N-Tier)

La arquitectura en capas es el modelo MÁS utilizado en sistemas corporativos. Separa las responsabilidades en niveles independientes, facilitando mantenimiento, escalabilidad y reutilización.

8.1.1. Arquitectura de 2 Capas (Cliente-Servidor)

Modelo clásico: un cliente (presentación + lógica) y un servidor (datos).

Ventajas: Simplicidad, bajo coste inicial, buena para aplicaciones pequeñas

Inconvenientes: No escala bien, lógica en cliente dificulta actualizaciones, problemas de rendimiento de red

Ejemplo en SAS: Aplicaciones legacy antiguas (facturación local de hospitales años 90). Ya casi no se usa.

8.1.2. Arquitectura de 3 Capas

El estándar actual para aplicaciones empresariales. Preguntaron sobre esto en el examen 2025 (Técnico Titulado Medio):

Pregunta Real Examen 2025 – TTM

En una arquitectura de tres niveles, ¿qué ventaja principal ofrece la capa intermedia de lógica de negocio?

A) Reduce el consumo de memoria en el servidor de base de datos

B) Permite la escalabilidad independiente y reutilización de la lógica empresarial ✓

C) Elimina la dependencia de un servidor de base de datos

D) Simplifica el desarrollo de la interfaz de usuario

✓ Respuesta Correcta: B

Arquitectura de 3 Capas – Desglose:

Capa de Presentación (Frontend): Interfaz de usuario (HTML/CSS/JavaScript, app móvil). Se ejecuta en el navegador o dispositivo del usuario.
Capa de Lógica de Negocio (Backend / Application Tier): Procesa las peticiones, aplica reglas de negocio, orquesta el acceso a datos. Se ejecuta en servidores de aplicación (JBoss, Tomcat, .NET Core).
Capa de Datos (Data Tier): Almacena y gestiona datos persistentes. Servidor de BBDD (Oracle, PostgreSQL, SQL Server).

Ventaja B es correcta porque:

Escalabilidad independiente: Puedes añadir más servidores de aplicación sin tocar la BBDD, o viceversa. Si la carga aumenta en procesamiento, escalas la capa 2. Si aumenta en consultas, escalas la capa 3.
Reutilización: La misma lógica de negocio puede servir a múltiples interfaces (web, móvil, APIs). Diraya web y ClicSalud+ app móvil comparten la misma lógica en el backend.
Mantenimiento: Cambios en reglas de negocio solo afectan a la capa 2, no hay que redistribuir clientes.

Ejemplo en SAS – Diraya:

Capa 1: Navegador web del médico (HTML/JS), app móvil enfermería
Capa 2: Servidores JBoss con aplicación Diraya (Java), reglas clínicas, validaciones, integración con Receta XXI
Capa 3: Clúster Oracle RAC con base de datos de historias clínicas

8.1.3. Arquitectura N-Capas (4+ capas)

Para sistemas muy complejos, se subdividen aún más las capas. Ejemplo típico:

Capa de Presentación
Capa de Servicios Web / APIs
Capa de Lógica de Negocio
Capa de Acceso a Datos (DAL)
Capa de Datos

8.2. Arquitectura Orientada a Servicios (SOA)

SOA es un paradigma arquitectónico donde la funcionalidad se expone como servicios reutilizables, interoperables y débilmente acoplados.

Pregunta Real Examen 2025 – TTM

¿Qué componente es esencial en una arquitectura orientada a servicios (SOA) para gestionar la comunicación entre servicios?

A) Oficina Técnica de Interoperabilidad (OTI)

B) Servidor de bases de datos centralizado (CDB)

C) Sistema de archivos distribuido (DFS)

D) El bus de servicios empresariales (ESB) ✓

✓ Respuesta Correcta: D) ESB

ESB (Enterprise Service Bus) es el componente central de SOA que actúa como «autopista de servicios». Sus funciones:

Enrutamiento: Dirige mensajes del servicio origen al servicio destino
Transformación: Convierte formatos de mensajes entre servicios (ej: XML a JSON)
Orquestación: Coordina llamadas a múltiples servicios para completar un proceso de negocio
Seguridad: Autenticación, autorización, cifrado de mensajes
Monitorización: Logs, trazabilidad, métricas de rendimiento

Ejemplo en SAS:

Imagina que ClicSalud+ (app móvil) necesita:

Consultar citas del paciente (servicio de Diraya)
Ver resultados de analíticas (servicio de laboratorio)
Acceder a recetas electrónicas (servicio de Receta XXI)

En lugar de que ClicSalud+ llame directamente a 3 servicios distintos con 3 protocolos diferentes, el ESB actúa como intermediario:

ClicSalud+ hace UNA llamada al ESB: «dame todo sobre el paciente 12345678A»
El ESB orquesta las 3 llamadas a servicios backend, transforma respuestas, las agrega y devuelve UN solo JSON a ClicSalud+

Tecnologías ESB en SAS: IBM Integration Bus (antes WebSphere ESB), MuleSoft, Apache ServiceMix

8.3. Arquitectura de Microservicios

La evolución moderna de SOA. En lugar de servicios grandes y monolíticos, múltiples microservicios pequeños, autónomos, cada uno con su BBDD.

            🔬 Características de Microservicios:
            Independencia: Cada microservicio se desarrolla, despliega y escala independientemente
Descentralización: No hay ESB central, comunicación directa (REST, gRPC, mensajería)
Responsabilidad única: Cada microservicio hace UNA cosa bien (principio SRP)
Tecnología heterogénea: Cada microservicio puede usar diferente lenguaje/BBDD
Gestión de fallos: Si un microservicio falla, no cae todo el sistema

        

Ya vimos la pregunta de examen 2025 sobre microservicios + arquitectura basada en eventos (EDA). La clave es entender que microservicios + contenedores (Docker) + orquestadores (Kubernetes) = futuro del SAS.

Ejemplo práctico: El portal ClicSalud+ se está rediseñando con microservicios:

Microservicio de autenticación (identic)
Microservicio de citas (Java + PostgreSQL)
Microservicio de resultados (Python + MongoDB)
Microservicio de notificaciones (Node.js + RabbitMQ)

Cada uno se despliega en contenedores Docker, orquestados con Kubernetes en Azure.

8.4. Arquitecturas Cloud

8.4.1. IaaS, PaaS, SaaS

Modelo	Qué Gestiona el Usuario	Qué Gestiona el Proveedor	Ejemplo en SAS
IaaS	SO, middleware, aplicaciones, datos	Hardware, virtualización, red, almacenamiento	VMs en Azure para nuevas aplicaciones
PaaS	Aplicaciones, datos	Hardware, SO, middleware, runtime	Azure App Service para ClicSalud+ (no gestionamos servidores)
SaaS	Solo uso de la aplicación	TODO (hardware, SO, aplicación, datos)	Office 365, Microsoft Teams (el SAS solo usa, Microsoft gestiona todo)

8.4.2. Cloud Híbrido y Cloud Bursting

Ya vimos la pregunta del examen 2025 sobre cloud bursting:

Pregunta Real Examen 2025 – TTM

En el contexto de la nube híbrida, ¿qué permite el «cloud bursting»?

A) Migración completa a la nube pública

B) Aislamiento total de la nube privada

C) Expansión temporal a la nube pública durante picos de demanda ✓

D) Eliminación de la necesidad de infraestructura local

✓ Respuesta Correcta: C

Cloud Bursting es una estrategia de cloud híbrido donde:

Normalmente, las aplicaciones corren en infraestructura on-premise (CPD del SAS)
Cuando hay picos de demanda (ej: campaña de vacunación masiva en ClicSalud+), se «expande» temporalmente a cloud pública (Azure/AWS) para absorber la carga extra
Una vez pasado el pico, se «contrae» de nuevo a on-premise

Ventajas:

No tienes que dimensionar on-premise para el pico máximo (que solo ocurre esporádicamente)
Aprovechas la elasticidad de cloud pública solo cuando la necesitas
Datos sensibles permanecen on-premise en condiciones normales

Ejemplo en SAS: Durante la campaña de vacunación COVID-19, ClicSalud+ tuvo picos de millones de accesos para pedir cita. Con cloud bursting, los servidores on-premise gestionaron la carga base, y Azure escaló automáticamente para absorber picos.

9. Evolución y Tendencias en Sistemas Informáticos

9.1. De Mainframes a Cloud

La evolución histórica nos ayuda a entender por qué las arquitecturas actuales son como son:

Década	Paradigma Dominante	Características
1960-1970	Mainframes centralizados	Procesamiento batch, terminales tontos, costoso, solo grandes organizaciones
1980-1990	Minicomputadoras y PCs	Descentralización, sistemas departamentales, aparece Unix/Linux
1990-2000	Cliente-Servidor	Redes locales, servidores x86, Windows NT/2000, bases de datos relacionales populares
2000-2010	Web y SOA	Internet, aplicaciones web, servicios web (SOAP/REST), arquitecturas orientadas a servicios
2010-2020	Cloud y Virtualización	IaaS/PaaS/SaaS, VMware/Hyper-V masivo, DevOps, contenedores (Docker)
2020-Actualidad	Cloud Híbrido, Edge, IA	Kubernetes, microservicios, serverless, edge computing, IA integrada, multi-cloud

9.2. Tendencias Actuales

            🚀 Tendencias en Arquitecturas de Sistemas (Relevantes para el SAS):
            Contenedorización y Kubernetes: El SAS está adoptando Docker + Kubernetes para nuevas aplicaciones. Ejemplo: ClicSalud+ en Azure Kubernetes Service (AKS).
Serverless / FaaS: Funciones as a Service. Ejecutar código sin gestionar servidores. Ejemplo: Azure Functions para procesamiento de notificaciones en ClicSalud+.
Edge Computing en IoMT: Procesar datos de dispositivos médicos IoT en el «borde» (en el hospital) antes de enviarlos a cloud. Ejemplo: monitorización de constantes en UCI procesada localmente.
IA/ML integrada: Modelos de IA embebidos en aplicaciones clínicas. Ejemplo: detección de retinopatía diabética en imágenes de fondo de ojo en Diraya.
Zero Trust Architecture: Seguridad perimetral está muerta. Verificación continua de identidad y contexto. Ejemplo: cada acceso a Diraya validado con MFA + análisis de riesgo.
Multi-cloud y Cloud Agnóstico: No depender de un solo proveedor. Usar Azure + AWS + on-premise. Herramientas: Terraform, Ansible para IaC (Infrastructure as Code).

        

9.3. Sistemas Departamentales vs Grandes Sistemas Centrales

Aunque los mainframes son cosa del pasado, aún existen debates sobre centralización vs descentralización:

Aspecto	Sistemas Departamentales	Grandes Sistemas Centrales
Gestión	Descentralizada, cada departamento gestiona su infraestructura	Centralizada, un equipo TIC gestiona todo
Escalabilidad	Limitada por recursos departamentales	Alta, pooling de recursos
Coste	Menor inversión inicial por departamento, pero costes duplicados	Mayor inversión inicial, economías de escala
Disponibilidad	Depende de cada departamento, riesgo de fallos aislados	Alta disponibilidad con arquitecturas redundantes
Integración	Difícil, silos de información	Fácil, datos centralizados
Seguridad	Difícil de auditar y homogeneizar	Políticas centralizadas, mejor control

Tendencia en el SAS: Migración de sistemas departamentales a sistemas centrales corporativos. Ejemplos:

Antes: Cada hospital tenía su servidor de aplicaciones local. Ahora: Diraya centralizado en CPD de Sevilla/Granada.
Antes: Cada centro con su Active Directory local. Ahora: AD corporativo único del SAS.
Antes: Backups locales en cinta en cada hospital. Ahora: Backup centralizado en cabinas SAN de CPDs.

10. Aplicación de Arquitecturas en el SAS

10.1. Mapa de Soluciones Digitales del SAS

El SAS tiene un portfolio extenso de sistemas corporativos. Todos comparten arquitecturas similares de alta disponibilidad, escalabilidad y seguridad:

Sistema	Función	Arquitectura	Tecnología
Diraya	Historia clínica digital única de Andalucía	3 capas, Oracle RAC, clúster aplicaciones	Java / JBoss, Oracle 19c RAC
Receta XXI	Receta electrónica	3 capas, integración con farmacias, HA crítica	Java, Oracle, mensajería JMS
BPS (Business Process Suite)	Gestión de procesos asistenciales	SOA con ESB, orquestación BPEL	Oracle SOA Suite, WebLogic
ClicSalud+	Portal ciudadano (citas, resultados)	Microservicios en cloud híbrido	Azure App Service, Node.js, PostgreSQL
InterSAS	Integración de sistemas (ESB corporativo)	SOA, mediación de servicios	IBM Integration Bus, MQ
BI Corporativo	Inteligencia de negocio, cuadros de mando	Data Warehouse, ETL, OLAP	Oracle, Pentaho, Tableau
GERHONTE	Gestión de recursos humanos	3 capas, integración con nómina	Java, Oracle
SIGLO	Sistema de gestión logística	3 capas, integración con proveedores	Java, Oracle

10.2. Red Corporativa SAS

Todos estos sistemas se conectan a través de la Red Corporativa del SAS, una WAN de alta capacidad y disponibilidad que une:

2 CPDs principales (Sevilla, Granada) con arquitectura activo-activo
40+ hospitales de alta resolución y complejos hospitalarios
1.500+ centros de salud de atención primaria
Conexión a redes autonómicas (Red SARA) y nacionales (Red NEREA)
Ancho de banda: enlaces de 1-10 Gbps entre CPDs, 100 Mbps – 1 Gbps a centros
Redundancia: doble operador, rutas geográficamente separadas

10.3. CPDs del SAS

El SAS opera 2 CPDs principales con arquitectura de alta disponibilidad geográfica:

Aspecto	CPD Sevilla	CPD Granada
Función	Producción principal (activo)	Producción secundaria / DR (activo/standby según sistema)
Clasificación TIER	TIER III	TIER III
Alimentación	Doble acometida eléctrica, UPS N+1, generadores diésel 2N	Doble acometida eléctrica, UPS N+1, generadores diésel 2N
Refrigeración	N+1, pasillos fríos/calientes	N+1, pasillos fríos/calientes
Conectividad	Doble operador, enlaces 10 Gbps	Doble operador, enlaces 10 Gbps
Seguridad Física	Control de acceso biométrico, videovigilancia 24/7, sistemas antiincendios	Control de acceso biométrico, videovigilancia 24/7, sistemas antiincendios

11. Casos Prácticos

Caso Práctico 1: Dimensionamiento de Clúster para Nuevo Hospital

📋 Enunciado:

Se va a inaugurar el nuevo Hospital Universitario de Jaén con 800 camas. Necesitas dimensionar el clúster de servidores que alojará las aplicaciones corporativas del SAS (Diraya, BPS, SIGLO).

Datos:

500 profesionales sanitarios trabajando simultáneamente en hora pico
Cada profesional realiza en media 40 transacciones/hora a las aplicaciones
Cada transacción requiere: 200 ms de CPU, 50 MB de RAM durante su ejecución, 10 KB de tráfico red
Objetivo de disponibilidad: 99.99% (cuatro nueves)
Arquitectura propuesta: Clúster activo-activo con balanceador, sin punto único de fallo

Preguntas:

¿Cuántos cores de CPU necesitas en total para soportar la carga pico?
¿Cuánta RAM total necesitas?
Si quieres redundancia N+1, ¿cuántos servidores mínimo necesitas si cada servidor tiene 16 cores y 128 GB RAM?
Si un servidor falla, ¿cuánto tiempo de downtime puedes permitirte al año para cumplir el objetivo de 99.99%?

Resolución:

1) Cores de CPU necesarios:

Transacciones por segundo en hora pico: 500 profesionales × 40 trans/hora ÷ 3600 seg/hora = 5.56 trans/seg
CPU necesaria: 5.56 trans/seg × 200 ms/trans = 1.112 ms de CPU por segundo = 1.112 cores
Con factor de seguridad (×2): ~3 cores mínimo, recomendado 4-6 cores

2) RAM total necesaria:

Transacciones concurrentes máximas: 5.56 trans/seg × 0.2 seg/trans = 1.11 transacciones concurrentes
RAM para transacciones: 1.11 × 50 MB = 55.5 MB
RAM para SO + middleware + cache: ~4 GB por servidor
Total por servidor: 4 GB base + margen → Con servidores de 128 GB, tienes margen de sobra.

3) Número de servidores con redundancia N+1:

Necesitas ~6 cores en total. Cada servidor tiene 16 cores.
Con 1 servidor soportas la carga, pero NO tienes redundancia.
Con N+1: necesitas 2 servidores (1 para carga + 1 de respaldo).
Respuesta: Mínimo 2 servidores. En la práctica, recomendaría 3 servidores (mayor margen, soportas 2 fallos).

4) Downtime permitido anual para 99.99%:

99.99% disponibilidad = 0.01% downtime
En un año (8760 horas): 8760 × 0.0001 = 0.876 horas = 52.56 minutos al año
Eso es ~4.4 minutos al mes.

Caso Práctico 2: Selección de Arquitectura para Portal Ciudadano

📋 Enunciado:

El SAS quiere renovar el portal ClicSalud+ para ofrecer nuevos servicios: videoconsultas, gestión de certificados COVID, acceso a informes médicos descargables, chatbot de salud con IA.

Requisitos:

Soporte para 2 millones de usuarios registrados (todo Andalucía)
Picos de carga impredecibles (ej: campaña de vacunación masiva)
Integración con múltiples sistemas backend del SAS (Diraya, Receta XXI, SIGLO)
Desarrollo ágil, despliegue continuo (CI/CD)
Multi-canal: web responsive, apps iOS/Android, integración con Alexa
Cumplimiento ENS ALTO, RGPD estricto

Opciones arquitectónicas:

A) Monolito Java en servidores on-premise del CPD Sevilla
B) Arquitectura de 3 capas con servidores físicos y Oracle DB
C) Microservicios en contenedores Docker, orquestados con Kubernetes en cloud híbrido (Azure + CPD SAS)
D) Arquitectura serverless completa en AWS Lambda

Pregunta: ¿Cuál es la arquitectura más adecuada y por qué?

Respuesta razonada:

Opción C) Microservicios + Kubernetes en cloud híbrido es la más adecuada por:

Escalabilidad elástica: Kubernetes auto-escala pods según demanda. Perfecto para picos impredecibles.
Desarrollo ágil: Equipos independientes para cada microservicio (citas, resultados, videoconsultas, chatbot). Despliegue independiente → CI/CD natural.
Multi-canal: Mismos microservices backend sirven a web, apps móviles, Alexa mediante APIs REST.
Integración: Cada microservicio integra con el backend SAS que necesita (citas → Diraya, recetas → Receta XXI). API Gateway gestiona autenticación única.
Cloud híbrido: Datos sensibles (historias clínicas completas) permanecen on-premise. Datos menos sensibles (disponibilidad de citas, resultados ya autorizados) pueden cachear en Azure para mejor rendimiento global.
ENS + RGPD: Azure tiene certificaciones ENS. Segregación de datos por microservicio facilita compliance. Logs distribuidos para auditoría.

Por qué las demás NO son óptimas:

A) Monolito on-premise: Difícil escalar elásticamente, no aprovecha cloud, desarrollo acoplado (equipo único, despliegues monolíticos).
B) 3 capas física: Mejor que monolito pero sigue siendo rígida. No elástica, requiere dimensionar para pico máximo, infrautilización habitual.
D) Serverless AWS puro: Podría funcionar, pero tiene limitaciones: dependencia total de un proveedor (vendor lock-in), más complejo gestionar datos sensibles en cloud público puro, costes pueden dispararse en picos sostenidos.

12. Cuestionario de Evaluación (30 Preguntas)

Aquí tienes 30 preguntas tipo test basadas en exámenes reales y en el contenido del tema. Intenta resolverlas ANTES de mirar las respuestas. Así entrenas de verdad.

Pregunta 1

¿Cuál de las siguientes afirmaciones sobre los sistemas informáticos y su jerarquía de niveles es correcta? (Pregunta Real Examen 2025)

A) Los niveles más bajos en la jerarquía se ocupan únicamente del almacenamiento de datos

B) En la jerarquía de niveles, el sistema operativo actúa como una capa de abstracción entre el hardware y el software de aplicación

C) En la jerarquía de sistemas informáticos, el software de aplicación interactúa directamente con el hardware

D) Los sistemas informáticos siempre siguen una jerarquía estricta, sin excepción

✓ Respuesta Correcta: B

El sistema operativo es la capa de abstracción que permite que las aplicaciones no tengan que gestionar directamente el hardware. Proporciona APIs y servicios para que las aplicaciones accedan a recursos (memoria, disco, red) de forma unificada.

Pregunta 2

¿Qué característica define mejor un sistema con alta disponibilidad? (Pregunta Real Examen 2025)

A) Puede dar acceso a un alto número de usuarios simultáneamente

B) Permite compartir un alto número de recursos

C) Permite ejecutar un alto número de tareas en paralelo por cada CPU

D) Garantiza un tiempo mínimo de inactividad y una recuperación rápida

✓ Respuesta Correcta: D

La alta disponibilidad se define por minimizar el tiempo de inactividad (downtime) y asegurar recuperación rápida ante fallos. Las demás opciones describen escalabilidad, paralelismo o características multiusuario, no disponibilidad.

Pregunta 3

¿Qué métrica se utiliza para medir la alta disponibilidad de un sistema de información? (Pregunta Real Examen 2023)

A) Tiempo medio entre fallos (MTBF)

B) Latencia

C) Tiempo de respuesta

D) Consumo de CPU

✓ Respuesta Correcta: A

MTBF (Mean Time Between Failures) mide el tiempo medio entre fallos. A mayor MTBF, más disponible es el sistema. La disponibilidad se calcula como: Disponibilidad = MTBF / (MTBF + MTTR).

Pregunta 4

A) Flexibilidad

B) Alta disponibilidad

C) Escalabilidad

D) Redundancia

✓ Respuesta Correcta: C

La escalabilidad es la capacidad de mantener o mejorar el rendimiento cuando aumenta la carga (usuarios, transacciones, datos). Flexibilidad se refiere a adaptarse a cambios de requisitos, HA a minimizar downtime, y redundancia es una técnica para lograr HA.

Pregunta 5

A) Arquitectura monolítica con implementación de caché distribuido

B) Arquitectura de microservicios combinada con una arquitectura basada en eventos (EDA)

C) Arquitectura tradicional cliente-servidor utilizando procesamiento centralizado

D) Sistema basado en una base de datos distribuida con sincronización eventual

✓ Respuesta Correcta: B

Microservicios permiten escalar cada funcionalidad independientemente. EDA (Event-Driven Architecture) desacopla componentes mediante mensajes asíncronos, mejorando escalabilidad y resiliencia. Es la arquitectura óptima para sistemas multicanal con alta carga variable.

Pregunta 6

¿Qué configuración de redundancia se asocia típicamente con un Centro de Proceso de Datos (CPD) clasificado como TIER IV? (Pregunta Real Examen 2025 – TTM)

A) N+1

B) 2N+1

C) N

D) 2N

✓ Respuesta Correcta: B

TIER IV se caracteriza por redundancia 2N+1, que significa doble capacidad (2N) más un elemento adicional de respaldo (+1). Esto garantiza tolerancia a fallos completa: cualquier componente puede fallar sin afectar la operación.

Pregunta 7

¿En qué consiste la técnica de almacenamiento de información denominada RAID 6? (Pregunta Real Examen 2025 – TTM)

A) La información se distribuye entre seis o más discos, actuando dos de ellos como bit de paridad

B) La información se distribuye entre tres o más discos, actuando uno de ellos como bit de paridad

C) La información se distribuye entre cuatro o más discos con capacidad utilizable aproximadamente la mitad

D) La información se distribuye entre cuatro o más discos, actuando dos de ellos como bit de paridad, tolerando fallo de cualquier dos discos

✓ Respuesta Correcta: D

RAID 6 usa striping con doble paridad distribuida. Requiere mínimo 4 discos, tolera fallo de CUALQUIER 2 discos simultáneamente. Capacidad utilizable = (N-2) × capacidad_disco. La doble paridad proporciona mayor protección que RAID 5 durante rebuilds.

Pregunta 8

En una arquitectura de tres niveles, ¿qué ventaja principal ofrece la capa intermedia de lógica de negocio? (Pregunta Real Examen 2025 – TTM)

A) Reduce el consumo de memoria en el servidor de base de datos

B) Permite la escalabilidad independiente y reutilización de la lógica empresarial

C) Elimina la dependencia de un servidor de base de datos

D) Simplifica el desarrollo de la interfaz de usuario

✓ Respuesta Correcta: B

La capa de lógica de negocio desacopla presentación y datos, permitiendo escalar cada capa independientemente. La misma lógica puede servir a múltiples interfaces (web, móvil, APIs). Facilita mantenimiento y reutilización de código.

Pregunta 9

¿Qué componente es esencial en una arquitectura orientada a servicios (SOA) para gestionar la comunicación entre servicios? (Pregunta Real Examen 2025 – TTM)

A) Oficina Técnica de Interoperabilidad (OTI)

B) Servidor de bases de datos centralizado (CDB)

C) Sistema de archivos distribuido (DFS)

D) El bus de servicios empresariales (ESB)

✓ Respuesta Correcta: D

El ESB (Enterprise Service Bus) es el componente central de SOA que gestiona: enrutamiento de mensajes, transformación de formatos, orquestación de servicios, seguridad, y monitorización. Actúa como «autopista» de comunicación entre servicios.

Pregunta 10

En el contexto de la nube híbrida, ¿qué permite el «cloud bursting»? (Pregunta Real Examen 2025 – TTM)

A) Migración completa a la nube pública

B) Aislamiento total de la nube privada

C) Expansión temporal a la nube pública durante picos de demanda

D) Eliminación de la necesidad de infraestructura local

✓ Respuesta Correcta: C

Cloud bursting permite expandir temporalmente desde infraestructura on-premise a cloud pública durante picos de demanda. Una vez pasado el pico, se contrae de nuevo. Aprovecha elasticidad de cloud sin dimensionar on-premise para picos excepcionales.

Pregunta 11

El Hospital Universitario cuenta con un sistema de virtualización basado en hiperconvergencia. ¿Qué significa dicha tecnología? (Pregunta Real Examen 2025 – TTM)

A) Arquitectura tradicional en capas, con almacenamiento, red y servidores independientes

B) Unifica computación, almacenamiento, red y software en un único sistema para minimizar complejidad

C) Implantación de servidores físicos no virtualizados

D) Solo utiliza virtualización por contenedores

✓ Respuesta Correcta: B

Hiperconvergencia (HCI) unifica en un único nodo: hipervisor, almacenamiento SAN virtualizado, red virtual (SDN) y software de gestión. Ventajas: simplicidad, escalabilidad horizontal (añadir nodos), alta disponibilidad integrada, reducción de costes.

Pregunta 12

A) Oracle Data Pump

B) Oracle RAC

C) Oracle ASM

D) Oracle Data Guard

✓ Respuesta Correcta: C

Oracle ASM (Automatic Storage Management) es un gestor de volúmenes específico para Oracle que distribuye automáticamente datos entre discos (striping), proporciona redundancia (mirroring) y simplifica gestión sin necesidad de LVM o sistemas de archivos tradicionales.

Pregunta 13

¿Qué nivel de disponibilidad corresponde a un sistema que puede estar inactivo como máximo 52.56 minutos al año?

A) 99.9% (tres nueves)

B) 99.95%

C) 99.99% (cuatro nueves)

D) 99.999% (cinco nueves)

✓ Respuesta Correcta: C

99.99% disponibilidad = 0.01% downtime. En un año (8760 horas): 8760 × 0.0001 = 0.876 horas = 52.56 minutos. Este es el objetivo típico para sistemas críticos del SAS como Diraya.

Pregunta 14

En un clúster de alta disponibilidad con configuración activo-pasivo, ¿qué ocurre cuando el nodo activo falla?

A) El servicio se interrumpe hasta intervención manual

B) El nodo pasivo detecta el fallo y toma automáticamente el relevo (failover)

C) La carga se redistribuye entre todos los nodos activos restantes

D) Se reinicia automáticamente el nodo activo sin cambio de configuración

✓ Respuesta Correcta: B

En configuración activo-pasivo (active-standby), el nodo pasivo monitoriza el activo. Si detecta fallo, ejecuta un failover automático: asume la IP virtual, monta almacenamiento compartido y reanuda el servicio. Ejemplo: Oracle Data Guard para Diraya.

Pregunta 15

¿Cuál es la principal diferencia entre escalabilidad vertical (scale up) y horizontal (scale out)?

A) Vertical añade más servidores, horizontal añade más recursos a un servidor

B) Vertical aumenta recursos de un servidor, horizontal añade más servidores

C) Vertical es más cara, horizontal es más barata en todos los casos

D) Vertical requiere cambio de arquitectura, horizontal no

✓ Respuesta Correcta: B

Escalabilidad vertical (scale up) = aumentar potencia de un servidor individual (más CPU, RAM). Límite físico, más cara. Escalabilidad horizontal (scale out) = añadir más servidores y distribuir carga. Escalabilidad casi ilimitada, mejor coste-beneficio, mayor complejidad arquitectónica.

Pregunta 16

¿Qué técnica de RAID proporciona el mejor rendimiento para bases de datos con alta carga de escrituras y lecturas simultáneas, manteniendo redundancia?

A) RAID 0 (striping sin paridad)

B) RAID 1 (mirroring)

C) RAID 5 (striping con paridad distribuida)

D) RAID 10 (combinación de mirroring y striping)

✓ Respuesta Correcta: D

RAID 10 (1+0) combina ventajas de RAID 1 (redundancia por mirroring) y RAID 0 (rendimiento por striping). Excelente para lecturas y escrituras, tolera múltiples fallos (1 disco por cada par). Es el RAID óptimo para BBDD de alto rendimiento como Oracle en Diraya. Coste: 50% capacidad útil.

Pregunta 17

En una arquitectura de microservicios, ¿cuál es la práctica recomendada para gestionar la configuración de cada microservicio?

A) Configuración embebida en el código de cada microservicio

B) Configuración centralizada en un servidor de configuración (ej: Spring Cloud Config)

C) Configuración duplicada en cada instancia de microservicio

D) Configuración gestionada manualmente en cada despliegue

✓ Respuesta Correcta: B

En microservicios, la configuración debe estar externalizada y centralizada. Herramientas como Spring Cloud Config, Consul, o Azure App Configuration permiten cambiar configuración sin recompilar ni redesplegar. Facilita gestión de múltiples entornos (dev, test, prod) y múltiples instancias de microservicios.

Pregunta 18

¿Qué métrica de rendimiento mide la cantidad de trabajo procesado por unidad de tiempo en un sistema informático?

A) Latencia

B) Tiempo de respuesta

C) Throughput

D) Jitter

✓ Respuesta Correcta: C

Throughput (rendimiento) mide la cantidad de trabajo procesado por unidad de tiempo (transacciones/seg, consultas/seg, GB/seg). Latencia es el retardo mínimo para procesar una petición. Tiempo de respuesta incluye latencia + tiempo de procesamiento + tiempo de espera. Jitter es variabilidad en latencia.

Pregunta 19

En el modelo de cloud computing IaaS (Infrastructure as a Service), ¿qué gestiona el usuario y qué gestiona el proveedor?

A) Usuario: solo aplicaciones. Proveedor: todo lo demás

B) Usuario: SO, middleware, aplicaciones. Proveedor: hardware, virtualización, red

C) Usuario: nada. Proveedor: todo

D) Usuario: hardware. Proveedor: SO y aplicaciones

✓ Respuesta Correcta: B

En IaaS, el proveedor gestiona la infraestructura física (hardware, virtualización, red, almacenamiento). El usuario gestiona desde el sistema operativo hacia arriba (SO, middleware, aplicaciones, datos). Ejemplo: VMs en Azure donde el SAS instala y gestiona Linux/Windows pero no el hardware subyacente.

Pregunta 20

En una arquitectura de alta disponibilidad, ¿qué protocolo es el más utilizado para la detección automática de fallos y el cambio automático de servicios entre nodos en clústeres Linux?

A) SNMP (Simple Network Management Protocol)

B) NTP (Network Time Protocol)

C) Heartbeat / Corosync + Pacemaker

D) LDAP (Lightweight Directory Access Protocol)

✓ Respuesta Correcta: C

Heartbeat (o su evolución Corosync) junto con Pacemaker forman la solución estándar en Linux para clústeres de alta disponibilidad. Heartbeat/Corosync gestionan la comunicación entre nodos (latido del corazón) y detectan fallos, mientras Pacemaker gestiona los recursos y ejecuta el failover automático. Ampliamente usado en el SAS para servicios críticos.

Pregunta 21

¿Qué ventaja fundamental proporciona la tecnología de almacenamiento SAN (Storage Area Network) frente al almacenamiento DAS (Direct Attached Storage) en entornos hospitalarios?

A) Mayor simplicidad de configuración y gestión

B) Coste inicial más reducido

C) Compartición de almacenamiento entre múltiples servidores y mayor consolidación

D) No requiere infraestructura de red dedicada

✓ Respuesta Correcta: C

SAN permite compartir almacenamiento entre múltiples servidores mediante una red dedicada (Fibre Channel o iSCSI). Ventajas: consolidación del almacenamiento, provisión flexible, snapshots centralizados, alta disponibilidad mediante paths redundantes. En el SAS, las SAN soportan clústeres Oracle RAC y VMware vSphere para compartir datastores.

Pregunta 22

En el contexto de la planificación de capacidad, ¿qué métrica es fundamental para determinar cuándo es necesario ampliar la infraestructura en un CPD del SAS? (Basada en Tema Real)

A) El número total de usuarios registrados en el sistema

B) La utilización media de CPU, memoria, almacenamiento y red durante períodos pico

C) El número de incidencias registradas en ayudaDIGITAL

D) La antigüedad del hardware instalado

✓ Respuesta Correcta: B

La planificación de capacidad se basa en métricas de utilización real de recursos durante períodos pico. Si CPU, memoria o almacenamiento superan umbrales críticos (típicamente 70-80% sostenido), se requiere ampliación. Se analizan tendencias históricas y proyecciones de crecimiento. Herramientas: VMware vRealize, Zabbix, Grafana para monitorización continua.

Pregunta 23

¿Qué característica define mejor un mainframe moderno frente a los servidores departamentales x86?

A) Menor coste total de propiedad (TCO) en todos los escenarios

B) Capacidad de ejecutar miles de máquinas virtuales simultáneas con altísima fiabilidad (99.999%)

C) Mayor facilidad de administración por personal no especializado

D) Mejor rendimiento en aplicaciones web de baja latencia

✓ Respuesta Correcta: B

Los mainframes (IBM Z series) están diseñados para cargas masivas de transacciones con fiabilidad extrema. Un único mainframe puede ejecutar miles de máquinas virtuales Linux y procesar billones de transacciones con disponibilidad de 99.999% o superior. Su RAS (Reliability, Availability, Serviceability) es superior. En el SAS, aunque se usan principalmente servidores x86, algunos sistemas legacy críticos pueden requerir mainframes.

Pregunta 24

En la metodología de planificación de sistemas informáticos, ¿qué documento establece la visión a largo plazo (3-5 años) de la evolución tecnológica y las inversiones necesarias en el SAS?

A) Plan Operativo Anual TIC

B) Plan Director de Sistemas de Información (PDSI)

C) Plan de Contingencia y Continuidad

D) Política de Seguridad de la Información

✓ Respuesta Correcta: B

El Plan Director de Sistemas de Información (PDSI) es el documento estratégico que define la visión, objetivos, proyectos y recursos TIC a medio-largo plazo (3-5 años). Se alinea con la estrategia asistencial del SAS. Define prioridades de inversión, evolución de aplicaciones, infraestructuras y seguridad. Se revisa periódicamente y se desglosa en planes anuales operativos.

Pregunta 25

¿Cuál es el objetivo principal del dimensionamiento de servidores en la fase de diseño de un nuevo sistema de información hospitalario?

A) Seleccionar los servidores con el máximo rendimiento disponible en el mercado

B) Equilibrar requisitos de rendimiento, disponibilidad y coste según las necesidades reales del sistema

C) Minimizar el coste inicial sin considerar el crecimiento futuro

D) Estandarizar todos los servidores con la misma configuración

✓ Respuesta Correcta: B

El dimensionamiento correcto balancea rendimiento requerido, nivel de disponibilidad (SLA), escalabilidad futura y coste. Se consideran: número de usuarios concurrentes, transacciones/segundo, crecimiento proyectado (3-5 años), tolerancia a fallos. Metodologías: benchmarks, pruebas de carga, dimensionamiento basado en sistemas similares. Evita sobredimensionamiento (desperdicio) y subdimensionamiento (problemas de rendimiento).

Pregunta 26

En una arquitectura de contenedores con Kubernetes, ¿qué componente se encarga de la distribución y balanceo de tráfico hacia los pods que ejecutan una aplicación?

A) ConfigMap

B) Service

C) PersistentVolume

D) Namespace

✓ Respuesta Correcta: B

En Kubernetes, un Service es una abstracción que define un conjunto lógico de Pods y una política para acceder a ellos. Actúa como balanceador de carga interno, distribuyendo el tráfico entre los Pods disponibles. Tipos de Services: ClusterIP (interno), NodePort (expone puerto), LoadBalancer (integración con balanceadores externos). Cada vez más usado en el SAS para microservicios y aplicaciones cloud-native.

Pregunta 27

¿Qué parámetro del sistema operativo Linux permite aumentar el número máximo de ficheros abiertos simultáneamente para soportar bases de datos de alto rendimiento como Oracle?

A) maxproc

B) ulimit -n (o fs.file-max en sysctl)

C) swappiness

D) tcp_keepalive

✓ Respuesta Correcta: B

El parámetro ulimit -n controla el límite de descriptores de archivo abiertos por proceso. Para BBDD como Oracle con miles de conexiones concurrentes, se debe aumentar este límite (típicamente a 65536 o más). Se configura en /etc/security/limits.conf o vía sysctl (fs.file-max para límite global). Síntoma de límite insuficiente: errores «Too many open files».

Pregunta 28

En un sistema de almacenamiento enterprise, ¿qué tecnología permite tomar instantáneas (snapshots) del estado de un volumen en un momento dado sin detener las aplicaciones?

A) RAID 0

B) Copy-on-Write (CoW)

C) Deduplicación en línea

D) Thin provisioning

✓ Respuesta Correcta: B

Copy-on-Write (CoW) es la técnica que permite crear snapshots instantáneos. Cuando se crea un snapshot, inicialmente no se copia nada. Solo cuando un bloque del volumen original va a modificarse, se copia primero a un área de snapshot. Así el snapshot preserva el estado en ese momento. Usado en SAN, NAS y sistemas de archivos como ZFS, Btrfs. Crítico para backups sin parada de servicios en el SAS.

Pregunta 29

¿Qué arquitectura de procesador es predominante en los servidores enterprise actuales x86-64?

A) ARM

B) SPARC

C) Intel Xeon y AMD EPYC

D) IBM POWER

✓ Respuesta Correcta: C

Intel Xeon y AMD EPYC dominan el mercado de servidores x86-64. Xeon: tradicional líder, múltiples generaciones (Cascade Lake, Ice Lake, Sapphire Rapids). AMD EPYC: ganando cuota con más cores y mejor rendimiento/precio. ARM emerge en cloud (AWS Graviton) pero aún minoritario en datacenters tradicionales. En el SAS, la infraestructura se basa principalmente en servidores Intel Xeon con VMware vSphere.

Pregunta 30

En una estrategia de backup 3-2-1, ¿qué significa exactamente este esquema?

A) 3 copias, 2 ubicaciones diferentes, 1 administrador

B) 3 copias de los datos, en 2 tipos de medios diferentes, 1 copia offsite

C) 3 servidores, 2 redes, 1 firewall

D) 3 días de retención, 2 backups diarios, 1 backup mensual

✓ Respuesta Correcta: B

La regla 3-2-1 es un estándar de backup resiliente: 3 copias de los datos (original + 2 backups), en 2 tipos de medios diferentes (ej: disco + cinta o disco local + cloud), con 1 copia fuera del sitio principal (offsite). Protege contra fallos de hardware, desastres locales, ransomware. En el SAS: backups locales en SAN + replicación a CPD secundario + copia en cinta para archivo.

📊 Mapa Conceptual del Tema

┌─────────────────────────────────────────────────────────────────────────────┐ │ ARQUITECTURAS BÁSICAS DE SISTEMAS INFORMÁTICOS │ │ (Tema 22 – SAS) │ └─────────────────────────────────────────────────────────────────────────────┘ │ ┌──────────────────────┴────────────────────────┐ │ │ ┌───────▼────────┐ ┌───────▼────────┐ │ ARQUITECTURAS │ │ PLANIFICACIÓN │ │ BÁSICAS │ │ DE SISTEMAS │ └───────┬────────┘ └───────┬────────┘ │ │ ┌───────────┼───────────┐ ┌──────────┼──────────┐ │ │ │ │ │ │ ┌───▼───┐ ┌───▼───┐ ┌───▼───┐ ┌───▼───┐ ┌───▼───┐ ┌───▼───┐ │Cliente│ │Cliente│ │Dis- │ │ PDSI │ │Capaci-│ │Análi- │ │Servi- │ │Servi- │ │tribui-│ │3-5 │ │dad │ │sis │ │dor │ │dor 3 │ │da │ │años │ │Sizing │ │Costes │ │2 cap. │ │capas │ │SOA │ └───────┘ └───────┘ └───────┘ └───────┘ └───┬───┘ └───┬───┘ │ │ ┌──────┴───┐ └─────┐ │ │ │ Presenta- Lógica Microser- ción Negocio vicios │ │ │ [Web/App] [Middleware] [Contenedores] │ │ │ └──────────┴────────────┘ │ ┌──────▼──────┐ │ Persistencia│ │ (BBDD/SAN) │ └─────────────┘ ┌─────────────────────────────────────────────────────────────────────────────┐ │ CARACTERÍSTICAS CRÍTICAS SISTEMAS │ └─────────────────────────────────────────────────────────────────────────────┘ │ ┌──────────────┬───────────────┼───────────────┬──────────────┐ │ │ │ │ │ ┌───▼───┐ ┌───▼───┐ ┌───▼───┐ ┌───▼───┐ ┌───▼───┐ │CAPACI-│ │RENDI- │ │FLEXI- │ │ESCALA-│ │ ALTA │ │ DAD │ │MIENTO │ │BILIDAD│ │BILIDAD│ │DISPONI│ └───┬───┘ └───┬───┘ └───┬───┘ └───┬───┘ └───┬───┘ │ │ │ │ │ CPU/RAM/ Throughput/ Adapta- Scale 99.99% Storage Latencia/ ción a Up/Out RTO/RPO Disk I/O IOPS Cambios SLA │ │ │ │ │ └──────────────┴──────────────┴──────────────┴──────────────┘ │ ┌────────▼────────┐ │ MÉTRICAS Y │ │ MONITORIZACIÓN │ └─────────────────┘ │ ┌────────────────┼────────────────┐ │ │ │ Zabbix Grafana VMware Nagios Prometheus vRealize ┌─────────────────────────────────────────────────────────────────────────────┐ │ TIPOS DE SISTEMAS (EVOLUCIÓN) │ └─────────────────────────────────────────────────────────────────────────────┘ │ ┌──────────────┬───────────────┼───────────────┬──────────────┐ │ │ │ │ │ ┌───▼───┐ ┌───▼───┐ ┌───▼───┐ ┌───▼───┐ ┌───▼───┐ │ MAIN- │ │DEPARTA│ │SERVI- │ │CLOUD │ │EDGE/ │ │ FRAME │ │MENTA- │ │DORES │ │HÍBRIDO│ │ IoT │ │(Legacy) │LES │ │x86-64 │ │ │ │ │ └───┬───┘ └───┬───┘ └───┬───┘ └───┬───┘ └───┬───┘ │ │ │ │ │ IBM Z Servidores Xeon/EPYC IaaS/PaaS Procesa- 99.999% Medios Cluster SaaS miento Miles VM Workgroup Virtualiz. Azure/AWS Distrib. │ │ │ │ │ └──────────────┴──────────────┴──────────────┴──────────────┘ │ ┌────────────▼────────────┐ │ TENDENCIAS ACTUALES: │ │ · Hiperconvergencia │ │ · Contenedores/K8s │ │ · Serverless │ │ · Edge Computing │ └─────────────────────────┘ ┌─────────────────────────────────────────────────────────────────────────────┐ │ ALTA DISPONIBILIDAD │ └─────────────────────────────────────────────────────────────────────────────┘ │ ┌────────────────┼────────────────┐ │ │ │ ┌───▼───┐ ┌───▼───┐ ┌───▼───┐ │CLÚSTER│ │REPLI- │ │BALANC.│ │ HA │ │CACIÓN │ │ CARGA │ └───┬───┘ └───┬───┘ └───┬───┘ │ │ │ Active/Passive Síncrona Round Robin Active/Active Asíncrona Least Conn Heartbeat/ Storage Health Check Corosync Replication HAProxy/F5 │ │ │ └────────────────┴────────────────┘ │ ┌────────────────▼────────────────┐ │ COMPONENTES HA EN SAS: │ │ · Oracle RAC (Diraya) │ │ · VMware HA/DRS │ │ · RAID 10/SAN Multipath │ │ · Backup 3-2-1 │ │ · Failover Automático │ │ · RTO < 4h / RPO < 1h │ └─────────────────────────────────┘ ┌─────────────────────────────────────────────────────────────────────────────┐ │ ALMACENAMIENTO Y VIRTUALIZACIÓN │ └─────────────────────────────────────────────────────────────────────────────┘ │ ┌────────────────┼────────────────┐ │ │ │ ┌───▼───┐ ┌───▼───┐ ┌───▼───┐ │ RAID │ │ SAN │ │VIRTUA-│ │ │ │ NAS │ │LIZACIÓN│ └───┬───┘ └───┬───┘ └───┬───┘ │ │ │ RAID 0,1,5,6,10 FC/iSCSI VMware vSphere Rendimiento EMC/NetApp Hyper-V Redundancia Consolidación KVM/Xen Hot Spare Snapshots Containers/Docker │ │ │ Oracle ASM Shared Storage VM/Template LVM/ZFS Thin Provision Live Migration │ │ │ └────────────────┴────────────────┘ │ ┌────────────▼────────────┐ │ TECNOLOGÍAS SAS: │ │ · VMware vSphere 8.x │ │ · SAN Fibre Channel │ │ · Oracle ASM (Diraya) │ │ · Backup Veeam/Networker│ │ · Replicación CPD │ └─────────────────────────┘

📚 Estrategias de Estudio y Consejos Prácticos

🎯 Enfoque Recomendado para Este Tema

El Tema 22 es fundamental y muy preguntado en las oposiciones del SAS. No solo requiere conocimiento teórico, sino también comprensión práctica de cómo se aplican estas arquitecturas en entornos sanitarios reales.

📋 Plan de Estudio Sugerido (12-15 horas)

Fase 1: Comprensión de Conceptos Base (4-5 horas)

Domina primero los conceptos fundamentales antes de profundizar en tecnologías específicas:

Arquitecturas básicas: Cliente-servidor, 3 capas, distribuida, microservicios. Dibuja diagramas de cada una y entiende sus ventajas/desventajas.
Las 5 características críticas: Capacidad, Rendimiento, Flexibilidad, Escalabilidad, Alta Disponibilidad. Crea una tabla comparativa con ejemplos del SAS.
Métricas clave: MTBF, MTTR, RTO, RPO, disponibilidad 99.9% vs 99.99%. Calcula ejemplos de downtime anual.

Fase 2: Profundización Técnica (5-6 horas)

Ahora entra en los detalles técnicos que son objeto frecuente de preguntas:

Clústeres de HA: Active/Passive vs Active/Active, protocolos (Heartbeat, Corosync, Pacemaker). Casos SAS: Oracle RAC para Diraya.
Almacenamiento: RAID (especialmente 1, 5, 10), SAN vs NAS, Oracle ASM. Repasa las preguntas sobre ASM de exámenes reales.
Virtualización: Hiperconvergencia, VMware vSphere, migración en caliente. Relaciona con la infraestructura actual del SAS.
Cloud híbrido: IaaS, PaaS, SaaS. Diferencias de responsabilidad entre usuario y proveedor.

Fase 3: Práctica con Preguntas y Casos Reales (3-4 horas)

La mejor forma de consolidar:

Resuelve TODAS las preguntas de este tema sin mirar las respuestas primero. Anota tus dudas.
Revisa exámenes reales anteriores: Busca preguntas sobre arquitecturas, RAID, disponibilidad. Identifica patrones.
Crea flashcards con preguntas tipo: «¿Qué RAID usar para BBDD críticas?» → RAID 10 (rendimiento + redundancia).
Practica casos prácticos: «Dimensiona un sistema para 5000 usuarios concurrentes en Diraya». Justifica: CPU, RAM, almacenamiento, HA.

⚠️ Errores Comunes a Evitar

Confundir escalabilidad con alta disponibilidad: Escalabilidad = soportar más carga. HA = minimizar downtime.
No diferenciar RAID 5 y RAID 10: RAID 5 es más eficiente en espacio pero RAID 10 es mejor para rendimiento de escritura (BBDD).
Olvidar la diferencia entre RTO y RPO: RTO = tiempo hasta recuperar servicio. RPO = datos que puedo perder (tiempo desde último backup).
No relacionar teoría con SAS: Siempre piensa: «¿Cómo se aplica esto en Diraya, en los CPDs del SAS, en la Red Corporativa?»

🔗 Conexiones con Otros Temas del Temario

            Tema 12 (ITIL): La planificación de capacidad es un proceso de ITIL. La gestión de la disponibilidad también.
Tema 21 (Concepto de sistema informático): Complementa este tema con la parte de componentes físicos y lógicos.
Tema 23 (Sistemas Operativos): Los conceptos de HA en SO (clústeres Linux) se conectan directamente.
Tema 33-34 (BBDD): Arquitecturas de BBDD (Oracle RAC, ASM) son parte integral de sistemas de HA.
Tema 35-36 (Seguridad y ENS): La disponibilidad es uno de los tres pilares de la seguridad (junto con confidencialidad e integridad).

        

💡 Consejo de Esteban Castro

Este tema es el corazón de la infraestructura TIC del SAS. Si lo dominas, no solo aprobarás preguntas en el examen, sino que estarás preparado para tomar decisiones técnicas reales cuando entres en el puesto. Piensa siempre en términos de:

¿Qué pasa si este servidor cae a las 9 AM un lunes?
¿Cuánto downtime puedo permitir en Diraya?
¿Cómo escalo si el número de usuarios se duplica?

Estas preguntas son las que te harán en casos prácticos, y son las que enfrentarás en tu día a día como Técnico Especialista en Informática del SAS. ¡Mucho ánimo con el estudio! 💪

📖 Referencias Bibliográficas y Normativas

📜 Marco Normativo y Estratégico del SAS

Plan Director de Sistemas de Información del SAS 2020-2024 – Define la estrategia TIC a medio plazo, prioridades de inversión en infraestructura y aplicaciones.
Política de Seguridad de las Tecnologías de la Información y Comunicaciones del SAS (actualización 2023) – Establece requisitos de disponibilidad, confidencialidad e integridad para sistemas corporativos.
Decreto 534/2021, de 13 de julio, por el que se regula la Administración Electrónica en el Servicio Andaluz de Salud – Marco legal para la digitalización y requisitos de sistemas de información.
Plan de Transformación Digital del Sistema Sanitario Público de Andalucía 2022-2027 – Visión estratégica de la evolución tecnológica, incluyendo cloud híbrido y modernización de infraestructuras.

📚 Estándares y Metodologías de Referencia

ISO/IEC 20000-1:2018 – Information technology — Service management – Estándar internacional de gestión de servicios TI, base para planificación de capacidad y disponibilidad.
ITIL 4 Foundation (2019) – Marco de buenas prácticas, específicamente:
- Gestión de la Capacidad y el Rendimiento
- Gestión de la Disponibilidad
- Gestión de la Continuidad del Servicio
COBIT 2019 – Framework de gobierno y gestión de TI empresarial, incluye objetivos de gestión para arquitectura empresarial.
ISO/IEC 27001:2022 – Sistemas de gestión de la seguridad de la información – Incluye requisitos de disponibilidad y continuidad (Anexo A.17).

📘 Bibliografía Técnica Fundamental

Tanenbaum, A. S. & Bos, H. (2022). Modern Operating Systems (5th ed.). Pearson. – Capítulos sobre virtualización, sistemas distribuidos y arquitecturas.
Coulouris, G., Dollimore, J., Kindberg, T. & Blair, G. (2011). Distributed Systems: Concepts and Design (5th ed.). Addison-Wesley. – Referencia en arquitecturas distribuidas.
Hennessy, J. L. & Patterson, D. A. (2017). Computer Architecture: A Quantitative Approach (6th ed.). Morgan Kaufmann. – Fundamentos de arquitecturas de computadores y rendimiento.
Marcus, E. & Stern, H. (2003). Blueprints for High Availability (2nd ed.). Wiley. – Diseño de sistemas de alta disponibilidad, clústeres, RAID.
Limoncelli, T., Chalup, S. & Hogan, C. (2016). The Practice of System and Network Administration (3rd ed.). Addison-Wesley. – Gestión operativa de infraestructuras complejas.

🔧 Documentación Técnica de Fabricantes

VMware vSphere 8.0 Documentation – Guías de arquitectura, alta disponibilidad (HA, DRS, vMotion), dimensionamiento.
Oracle Database High Availability Documentation – Oracle RAC, Data Guard, ASM (Automatic Storage Management).
Red Hat Enterprise Linux 9 – High Availability Add-On – Pacemaker, Corosync, configuración de clústeres Linux.
Microsoft Azure Architecture Center – Patrones de arquitectura cloud, alta disponibilidad, disaster recovery.
Dell EMC Storage Best Practices – RAID, SAN, snapshots, replicación.

🌐 Recursos Online y Comunidades

The Open Group – TOGAF (www.opengroup.org) – Framework de arquitectura empresarial, planificación estratégica de TI.
NIST Special Publications (SP 800 Series) – Guías de seguridad y disponibilidad de sistemas.
SNIA (Storage Networking Industry Association) – Estándares y mejores prácticas en almacenamiento.
VMware Blogs – Artículos técnicos sobre diseño de infraestructuras virtualizadas.
High Scalability (highscalability.com) – Casos reales de arquitecturas escalables de grandes empresas.

🎓 Recomendaciones Específicas para la Oposición

Para la preparación de este tema, prioriza:

Documentación oficial del SAS sobre infraestructura actual (aunque no siempre es pública, busca presentaciones de jornadas técnicas).
Manuales de ITIL 4, especialmente los capítulos sobre Gestión de Capacidad y Disponibilidad.
Whitepapers de VMware sobre diseño de entornos vSphere para sanidad (casos de uso similares al SAS).
Documentación de Oracle sobre RAC y ASM, muy relevante para sistemas críticos como Diraya.
Guías de dimensionamiento de fabricantes (Dell, HPE, Cisco) para entender metodologías de sizing.

⚖️ Legislación Complementaria Relevante

Real Decreto 311/2022, sobre el Esquema Nacional de Seguridad (ENS) – Requisitos de disponibilidad (artículos sobre categorización).
Reglamento (UE) 2016/679 (RGPD) – Artículo 32 sobre medidas técnicas y organizativas (incluye disponibilidad).
Ley 39/2015, de Procedimiento Administrativo Común – Requisitos de disponibilidad de sistemas de administración electrónica.

🔍 Palabras Clave del Tema (Keywords)

Keywords principales:

Arquitecturas sistemas informáticos SAS
Planificación capacidad TIC sanitaria
Alta disponibilidad Diraya
Escalabilidad sistemas hospitalarios
RAID 10 bases de datos
Oracle RAC ASM Andalucía
Clústeres alta disponibilidad Linux
VMware vSphere sanidad
Hiperconvergencia CPD SAS
Cloud híbrido IaaS PaaS
RTO RPO continuidad negocio
SAN NAS almacenamiento enterprise
Dimensionamiento servidores
Arquitectura 3 capas microservicios
MTBF MTTR disponibilidad 99.99%