UD4 · Actualización de componentes

Objetivos de aprendizaje

Al finalizar esta unidad, el alumno sera capaz de:

• Identificar versiones instaladas y detectar componentes obsoletos mediante herramientas especializadas
• Clasificar los tipos de actualizaciones y aplicar el procedimiento adecuado en cada caso
• Ejecutar actualizaciones de sistema y paquetes Python con estrategia de backup y rollback
• Verificar la estabilidad del sistema tras una actualización mediante pruebas estructuradas
• Documentar los cambios aplicados siguiendo el modelo ITIL de gestion del cambio
• Gestionar el fin de ciclo de vida del hardware de forma segura y sostenible (RAEE, borrado seguro, desinstalacion de licencias)

Resultado de aprendizaje: Actualiza los componentes de equipos, programas y aplicaciones garantizando el funcionamiento y la compatibilidad del sistema.

Revision de versiones — herramientas de deteccion (I)

Sistema operativo y controladores

# Version del sistema operativo
lsb_release -a
cat /etc/os-release

# Version del kernel de Linux
uname -r

# Controlador NVIDIA instalado
nvidia-smi
cat /proc/driver/nvidia/version

# Version del toolkit CUDA
nvcc --version
/usr/local/cuda/bin/nvcc --version

# Actualizaciones de sistema disponibles (Debian/Ubuntu)
sudo apt update && apt list --upgradable 2>/dev/null

# Paquetes con actualizaciones de seguridad pendientes
apt list --upgradable 2>/dev/null | grep -i security

Revision de versiones — herramientas de deteccion (II)

Entornos Python y paquetes de IA

# Paquetes Python desactualizados en el entorno activo
pip list --outdated

# Formato tabla con version instalada y ultima disponible
pip list --outdated --format=columns

# Paquetes desactualizados en entorno virtual especifico
/opt/venvs/inference/bin/pip list --outdated

# Informacion detallada de un paquete concreto
pip show torch
pip show transformers

Tabla de ejemplo: estado de versiones en servidor de inferencia

Deteccion de obsolescencia — senales EOL (I)

Que significa End of Life (EOL)

Un componente llega a su fin de vida util cuando el fabricante o la comunidad deja de publicar parches de seguridad. A partir de ese momento, cualquier vulnerabilidad descubierta queda sin corregir.

Senales de obsolescencia a vigilar:

• El fabricante anuncia fecha de EOL (Ubuntu LTS: 5 anos de soporte estandar)
• Aparicion de CVEs sin parche disponible para la version instalada
• La libreria deja de ser compatible con nuevas versiones del controlador CUDA
• El proveedor de hardware deja de publicar firmware actualizado
• La distribucion de Linux elimina el paquete de sus repositorios oficiales

Fuentes de informacion autorizadas

Deteccion de obsolescencia — ciclos de vida (II)

Tabla de ciclos de vida de componentes clave en plataformas de IA

Regla practica: si un componente lleva mas de 12 meses sin recibir actualizaciones de seguridad, debe planificarse su sustitucion antes del proximo ciclo de mantenimiento.

Tipos de actualizaciones

Clasificacion segun alcance e impacto

Norma general de version semantica (SemVer)

MAYOR.MENOR.PARCHE — ejemplo: 2.3.1

• PARCHE (2.3.0 → 2.3.1): solo correccion de errores. Actualizar siempre.
• MENOR (2.2 → 2.3): nueva funcionalidad compatible. Actualizar con pruebas.
• MAYOR (1.x → 2.x): puede romper la API. Requiere analisis previo.

Procedimiento de aplicacion de parches — preparacion

Fase 1: evaluacion y backup

# 1. Documentar el estado actual antes de cualquier cambio
pip freeze > /backups/$(date +%Y%m%d)_requirements_before.txt
dpkg -l > /backups/$(date +%Y%m%d)_packages_before.txt
nvidia-smi > /backups/$(date +%Y%m%d)_nvidia_before.txt

# 2. Snapshot del disco del sistema (si se usa LVM)
sudo lvcreate -L10G -s -n snap_system /dev/vg0/system
# En entornos virtualizados: tomar snapshot de la VM antes

# 3. Crear un entorno de prueba clonado
python -m venv /opt/venvs/inference_test
cp -r /opt/venvs/inference/* /opt/venvs/inference_test/

# 4. Verificar espacio disponible antes de actualizar
df -h /
df -h /var

Principio del entorno de prueba (staging)

Toda actualizacion que pueda afectar a un servicio en produccion debe validarse primero en un entorno identico al productivo pero aislado. Solo se aplica en produccion tras superar las pruebas de verificacion.

Procedimiento de aplicacion de parches — ejecucion

Fase 2: aplicacion y rollback

# --- ACTUALIZACION DE PAQUETES DE SISTEMA (Debian/Ubuntu) ---

# Actualizar solo parches de seguridad
sudo unattended-upgrade --dry-run   # simulacion
sudo unattended-upgrade             # aplicacion real

# Actualizar un paquete especifico
sudo apt update && sudo apt install --only-upgrade nvidia-driver-550

# --- ACTUALIZACION DE PAQUETES PYTHON ---

# Actualizar un paquete a la version mas reciente estable
pip install --upgrade torch==2.3.1

# Actualizar todos los paquetes outdated (con precaucion)
pip list --outdated --format=freeze | grep -v '^\-e' | cut -d= -f1 | xargs pip install --upgrade

# Actualizar con restriccion de version para evitar rotura
pip install "transformers>=4.40,<5.0"

# --- ROLLBACK si algo falla ---

# Restaurar paquetes Python al estado anterior
pip install -r /backups/20240615_requirements_before.txt

# Rollback del controlador NVIDIA a la version anterior
sudo apt install nvidia-driver-535=535.129.03-0ubuntu1

Pruebas de verificacion post-actualizacion (I)

Smoke tests — verificacion rapida de que el sistema arranca

# 1. Verificar que el controlador NVIDIA sigue activo
nvidia-smi
# Salida esperada: tabla con GPU detectada, driver version, CUDA version

# 2. Verificar que Python y PyTorch cargan correctamente
python -c "import torch; print(torch.__version__); print(torch.cuda.is_available())"
# Salida esperada: 2.3.1  /  True

# 3. Verificar disponibilidad de GPU desde PyTorch
python -c "import torch; print(torch.cuda.get_device_name(0))"
# Salida esperada: NVIDIA A100 80GB PCIe  (o el modelo instalado)

# 4. Test de inferencia minima con un modelo cargado
python -c "
from transformers import pipeline
pipe = pipeline('text-classification', model='distilbert-base-uncased-finetuned-sst-2-english', device=0)
result = pipe('El sistema funciona correctamente')
print(result)
"

# 5. Verificar que el servicio de inferencia responde
curl -s http://localhost:8000/health | python -m json.tool

Pruebas de verificacion post-actualizacion (II)

Benchmarks de rendimiento GPU

# Monitorizar GPU durante una inferencia de prueba (cada 2 segundos)
nvidia-smi dmon -s pucvmet -d 2

# Columnas clave en la salida de nvidia-smi dmon:
# pwr  = potencia consumida (W)
# temp = temperatura (C)
# sm   = utilizacion de SM (%)
# mem  = utilizacion de memoria (%)
# enc/dec = actividad del codificador/decodificador de video

# Benchmark de memoria GPU con PyTorch
python -c "
import torch, time
device = 'cuda:0'
# Reservar un tensor grande para verificar VRAM disponible
x = torch.randn(4096, 4096, device=device)
start = time.time()
for _ in range(100):
    y = torch.matmul(x, x)
torch.cuda.synchronize()
elapsed = time.time() - start
print(f'VRAM libre: {torch.cuda.mem_get_info()[0]/1e9:.1f} GB')
print(f'Tiempo benchmark: {elapsed:.2f}s')
"

# Comparar latencia de inferencia antes y despues
# Guardar resultado en fichero para comparacion
echo "$(date) POST-UPDATE: $(python benchmark_inferencia.py)" >> /logs/benchmark_history.log

Criterio de exito: latencia de inferencia no debe aumentar mas de un 5 % respecto al valor registrado antes de la actualizacion.

Estabilidad del sistema — monitorizacion post-actualizacion (I)

Periodo de observacion recomendado

Tras cualquier actualizacion mayor de controlador, CUDA o framework de IA, se recomienda un periodo de monitorizacion activa de 48-72 horas antes de considerar la actualizacion estabilizada.

Metricas criticas a vigilar

Estabilidad del sistema — monitorizacion post-actualizacion (II)

Comandos de monitorizacion continua

# Ver errores del kernel relacionados con NVIDIA en tiempo real
sudo dmesg -w | grep -i nvidia

# Revisar el log del servicio de inferencia (Triton Inference Server)
sudo journalctl -u triton-server -f --since "1 hour ago"

# Consultar consumo de VRAM de todos los procesos GPU
nvidia-smi --query-compute-apps=pid,process_name,used_memory \
  --format=csv,noheader,nounits

# Watchdog simple: alertar si VRAM supera el 95 %
watch -n 10 "nvidia-smi --query-gpu=memory.used,memory.total \
  --format=csv,noheader,nounits | awk -F',' '{if(\$1/\$2 > 0.95) print \"ALERTA VRAM\", \$0}'"

# Exportar metricas GPU a fichero cada 5 minutos (48 h de observacion)
for i in $(seq 1 576); do
  echo "$(date +%Y-%m-%dT%H:%M:%S),$(nvidia-smi --query-gpu=temperature.gpu,\
memory.used,power.draw --format=csv,noheader,nounits)" \
    >> /logs/gpu_postupdate_$(date +%Y%m%d).csv
  sleep 300
done &

Documentacion de cambios

El registro de cambio (Change Log)

Toda actualizacion aplicada a un sistema en produccion debe quedar documentada. El estandar ITIL v4 denomina esto Registro de Cambio (Change Record). Es obligatorio para:

• Auditorias de seguridad (ISO 27001, ENS)
• Diagnostico de incidencias futuras
• Trazabilidad del estado del sistema

Formato de ticket de cambio ITIL (campos obligatorios)

Documentacion de cambios — registro practico

Plantilla de change log en formato Markdown

# Change Log — srv-inference-01

## CHG-2024-0312 | 2024-06-15 02:00 UTC | J. Garcia

**Tipo:** Urgente (parche de seguridad)
**Componente:** PyTorch 2.1.2 → 2.3.1
**Motivo:** CVE-2024-31583 (deserializacion insegura, CVSS 9.8)

### Acciones realizadas
1. Backup de requirements.txt en /backups/20240615_requirements_before.txt
2. Prueba en entorno staging durante 4 h — resultado: OK
3. Aplicacion en produccion: pip install torch==2.3.1
4. Reinicio del servicio Triton: systemctl restart triton-server

### Verificacion
- [x] nvidia-smi OK
- [x] torch.cuda.is_available() = True
- [x] Smoke test de inferencia OK
- [x] Latencia p99 dentro del umbral (delta: +1.8 %)

### Resultado: EXITO

Buena practica: almacenar los change logs en un repositorio Git dedicado a la configuracion del sistema (GitOps / IaC), de modo que cada cambio quede como un commit con autor y fecha.

Fin de ciclo de vida — planificacion de migracion

Cuando un componente llega a EOL

El fin de ciclo de vida (EOL) no es un evento repentino: debe planificarse con antelacion suficiente para evitar ventanas de exposicion sin parches de seguridad.

Proceso recomendado:

1. Deteccion temprana (12 meses antes del EOL): incluir en el inventario la fecha de EOL de cada componente critico.
2. Evaluacion de impacto (6-9 meses antes): identificar dependencias que deben migrar junto con el componente.
3. Proyecto de migracion (3-6 meses antes): planificar, presupuestar y probar la alternativa.
4. Migracion y validacion (1-2 meses antes): ejecutar la migracion en todos los entornos.
5. Cierre (antes del EOL): confirmar que ningun sistema en produccion usa la version retirada.

Borrado seguro de datos — normativa NIST SP 800-88

Antes de retirar o reutilizar cualquier medio de almacenamiento que haya contenido datos sensibles, es obligatorio aplicar un procedimiento de borrado seguro que garantice la irrecuperabilidad de la informacion.

La norma de referencia es NIST SP 800-88 Rev. 1 (Guidelines for Media Sanitization), que define tres niveles: Clear (sobrescritura), Purge (tecnicas mas robustas) y Destroy (destruccion fisica).

Fin de ciclo de vida — borrado seguro

Herramientas de borrado seguro en Linux

# --- SHRED: borrado seguro de un fichero o dispositivo ---

# Sobreescribir un fichero con 3 pasadas aleatorias y eliminarlo
shred -uzv -n 3 /datos/modelo_confidencial.pt

# Sobreescribir un disco completo (ADVERTENCIA: irreversible)
sudo shred -vz -n 3 /dev/sdb

# --- NWIPE: borrado de disco con interfaz interactiva ---
sudo apt install nwipe
sudo nwipe /dev/sdb
# Metodos disponibles: DoD 5220.22-M, Gutmann, PRNG, Random

# --- HDPARM: ATA Secure Erase (mas eficaz en SSD) ---
# Paso 1: verificar que el disco no esta congelado
sudo hdparm -I /dev/sda | grep -i frozen

# Paso 2: establecer contrasena temporal
sudo hdparm --security-set-pass TEMPORAL /dev/sda

# Paso 3: ejecutar Secure Erase
sudo hdparm --security-erase TEMPORAL /dev/sda

# --- NVME: borrado seguro de discos NVMe ---
sudo nvme format /dev/nvme0n1 --ses=1
# ses=1: User Data Erase (sobrescritura)
# ses=2: Cryptographic Erase (si el disco soporta encriptacion)

Para SSDs NVMe: el metodo recomendado por NIST SP 800-88 es Cryptographic Erase (--ses=2) cuando el disco soporta encriptacion de hardware, ya que la sobrescritura por pasadas no es eficaz en memorias flash.

Tratamiento de RAEE

Marco normativo

Los Residuos de Aparatos Electricos y Electronicos (RAEE) estan regulados en la Union Europea por la Directiva 2012/19/UE (refundicion), transpuesta en Espana mediante el Real Decreto 110/2015, de 20 de febrero, sobre residuos de aparatos electricos y electronicos.

Obligaciones del poseedor de RAEE profesional:

• No mezclar los RAEE con otros tipos de residuos
• Entregar los RAEE unicamente a gestores autorizados inscritos en el Registro de Produccion y Gestion de Residuos (RPGR)
• Conservar el justificante de entrega durante un minimo de 5 anos
• No exportar RAEE a paises terceros como residuo disfrazado de segunda mano

Proceso de entrega de hardware retirado

1. Identificacion: etiquetar el equipo como RAEE y registrarlo en el inventario como "pendiente de baja"
2. Borrado seguro: aplicar el procedimiento de borrado (ver diapositiva anterior) y documentarlo
3. Desinstalacion de licencias: retirar toda licencia propietaria antes de la entrega (ver siguiente diapositiva)
4. Embalaje: proteger el equipo para evitar rotura durante el transporte
5. Entrega al gestor autorizado: solicitar albaran de entrega como justificante
6. Baja en inventario: actualizar el inventario del sistema de gestion de activos (CMDB)

Desinstalacion de licencias

Por que es obligatorio antes de retirar el hardware

Las licencias de software propietario suelen estar vinculadas a un numero de serie de hardware o a un servidor de licencias. Si el hardware se retira sin desactivar la licencia:

• La licencia queda "consumida" sin uso productivo
• En licencias flotantes (concurrent), se reduce el numero de puestos disponibles
• Puede incurrirse en incumplimiento del acuerdo de licencia (EULA)

Procedimiento para productos comunes en entornos de IA

# Ejemplo: detener y limpiar un servidor de licencias FlexLM
sudo systemctl stop flexlm
sudo rm /etc/flexlm/license.dat
sudo systemctl disable flexlm

# Verificar que no quedan procesos lmgrd activos
ps aux | grep lmgrd

Sostenibilidad — eficiencia energetica y prolongacion de vida util

Reduccion de carga termica y energetica

En centros de datos con GPUs de alto rendimiento, la gestion termica y energetica es un factor critico tanto economico como medioambiental.

Tecnicas de ajuste en GPU NVIDIA:

# Ajuste del TDP (Total Design Power) de la GPU
# Reducir la potencia maxima al 80 % del TDP nominal
sudo nvidia-smi -pl 320   # GPU con TDP nominal de 400 W → limitar a 320 W

# Verificar el limite de potencia actual
nvidia-smi --query-gpu=power.limit,power.draw --format=csv

# Activar modo de gestion de energia persistente
sudo nvidia-smi -pm 1

# DVFS (Dynamic Voltage and Frequency Scaling): ajustar frecuencias
# Modo auto (el controlador ajusta segun carga)
sudo nvidia-smi --auto-boost-default=0
sudo nvidia-smi -ac 877,1410   # mem_clock,graphics_clock en MHz (A100)

Metricas de eficiencia energetica del centro de datos

Prolongacion de vida util: mantener las GPU a temperatura maxima por debajo de 75 C de forma sostenida puede extender su vida util varios anos, reduciendo la generacion de RAEE y el coste de reposicion.

Actividad practica

Auditoria de paquetes Python y plan de actualizacion

Objetivo: identificar paquetes desactualizados y CVEs abiertas en un entorno de inferencia, y generar un plan de actualizacion priorizado.

Pasos:

1. Activar el entorno virtual del servidor de inferencia:

   source /opt/venvs/inference/bin/activate
   

2. Generar el informe de paquetes desactualizados:

   pip list --outdated --format=columns > ~/auditoria_$(date +%Y%m%d).txt
   pip freeze > ~/requirements_actual.txt
   

3. Instalar y ejecutar pip-audit para detectar CVEs:

   pip install pip-audit
   pip-audit --format=columns
   pip-audit --format=json > ~/cves_$(date +%Y%m%d).json
   

4. Clasificar los hallazgos segun el tipo de actualizacion (parche de seguridad, bugfix, minor, major) y la urgencia (critica, alta, media, baja).

5. Redactar un plan de actualizacion con: componente, version actual, version objetivo, tipo de cambio, urgencia, riesgo estimado, ventana de mantenimiento propuesta y responsable.

Entregable: documento con el informe de pip-audit y el plan de actualizacion cumplimentado.

Puntos clave

• Detectar antes de actuar: usar apt list --upgradable, pip list --outdated y nvidia-smi como punto de partida de cualquier ciclo de mantenimiento.
• Clasificar la urgencia: no todas las actualizaciones son iguales. Un parche de seguridad con CVE critica no puede esperar; una actualizacion major requiere un proyecto de migracion formal.
• Backup y staging siempre: nunca aplicar una actualizacion directamente en produccion sin haber probado en un entorno equivalente y sin disponer de un plan de rollback documentado.
• Verificar la estabilidad: el trabajo no termina al aplicar el parche. El periodo de monitorizacion post-actualizacion de 48-72 h es parte del procedimiento.
• Documentar cada cambio: sin Change Record no hay trazabilidad. El modelo ITIL de gestion del cambio es el estandar en entornos profesionales.
• El fin de vida es predecible: planificar la migracion con 12 meses de antelacion evita urgencias, exposicion a vulnerabilidades y costes innecesarios.
• RAEE y borrado seguro son obligaciones legales: la Directiva 2012/19/UE y el RD 110/2015 no son opcionales. El justificante de entrega al gestor autorizado debe conservarse 5 anos.

Criterios de evaluacion

Navegación

← UD3 · Implementación de componentes…  ·  Volver al módulo  ·  UD5 · Resolución de incidencias en… →