LPIC & Hacking Vault

Notas Recientes

200.2 - Prediccion de necesidades

Se lee en 10 min

200.2 - Prediccion de necesidades

Introduccion

La prediccion de necesidades de recursos es la extension logica de la monitorizacion del uso actual. Mientras que el subtema 200.1 se centra en medir lo que esta ocurriendo ahora, este subtema se enfoca en analizar tendencias para anticipar las necesidades futuras del sistema.

Este subtema tiene un peso de 2 en el examen, lo que indica que se evaluan conceptos generales mas que detalles tecnicos profundos.

Fundamentos de la planificacion de capacidad

¿Que es la planificacion de capacidad?

La planificacion de capacidad es el proceso de determinar los recursos de infraestructura necesarios para satisfacer las demandas futuras de carga de trabajo. Implica:

  • Medicion: recopilar datos del uso actual de recursos
  • Analisis: identificar patrones y tendencias en los datos
  • Prediccion: estimar necesidades futuras basandose en las tendencias
  • Planificacion: disenar estrategias para satisfacer la demanda proyectada

Ciclo de la planificacion de capacidad

  Monitorizar --> Analizar --> Predecir --> Planificar --> Implementar
       ^                                                      |
       |______________________________________________________|

Este ciclo es continuo. Despues de implementar cambios, se debe seguir monitorizando para verificar que las predicciones fueron acertadas y ajustar el modelo segun sea necesario.

Analisis de tendencias de recursos

Tipos de tendencias

Las tendencias de uso de recursos pueden seguir distintos patrones:

  • Crecimiento lineal: el uso aumenta de forma constante y predecible (por ejemplo, almacenamiento que crece 50 GB al mes)
  • Crecimiento exponencial: el uso se acelera con el tiempo (por ejemplo, una aplicacion web que duplica usuarios cada trimestre)
  • Crecimiento estacional/ciclico: patrones que se repiten periodicamente (por ejemplo, mayor uso de CPU durante horarios laborales o picos de trafico en diciembre para tiendas en linea)
  • Crecimiento escalonado: aumentos bruscos asociados a eventos (por ejemplo, despliegue de una nueva aplicacion)

Fuentes de datos para el analisis

Las herramientas del subtema 200.1 son la base para recopilar datos historicos:

# Datos historicos de sar (dias anteriores)
$ sar -u -f /var/log/sysstat/sa15   # CPU del dia 15
$ sar -r -f /var/log/sysstat/sa15   # Memoria del dia 15
 
# Uso de disco a lo largo del tiempo
$ df -h  # Punto de datos actual para comparar con historicos
 
# Datos de collectd almacenados en RRD
# Tipicamente en /var/lib/collectd/rrd/

Para el examen: La recopilacion de datos historicos con herramientas como sar y collectd es fundamental para la prediccion de necesidades. Sin datos historicos no es posible identificar tendencias.

Metodologia de prediccion

Estimacion de crecimiento de disco

El caso mas comun y mas facil de predecir es el crecimiento del almacenamiento.

Ejemplo practico:

Datos recopilados durante 4 meses:
- Enero:   Uso de /home: 500 GB de 2 TB
- Febrero: Uso de /home: 560 GB de 2 TB
- Marzo:   Uso de /home: 620 GB de 2 TB
- Abril:   Uso de /home: 680 GB de 2 TB

Crecimiento mensual: ~60 GB/mes
Espacio disponible: 2000 - 680 = 1320 GB
Meses hasta llenar: 1320 / 60 = 22 meses

Conclusion: se necesitara ampliar el disco en aproximadamente 18 meses
(aplicando un margen de seguridad del 80% de ocupacion)

Para el examen: Se espera que puedas realizar calculos basicos de prediccion de crecimiento de disco. Siempre ten en cuenta un margen de seguridad (tipicamente, actuar cuando se alcanza el 80% de uso).

Estimacion de necesidades de memoria

La prediccion de memoria es mas compleja porque depende de las aplicaciones:

  • Numero de usuarios concurrentes esperados
  • Consumo de memoria por usuario/conexion
  • Crecimiento del dataset en aplicaciones de base de datos
  • Requerimientos de cache
Ejemplo:
- Servidor web actual: 200 conexiones concurrentes, 4 GB RAM usada
- Prevision: duplicar usuarios en 6 meses
- Estimacion: se necesitaran 8 GB RAM (mas margen)
- Recomendacion: ampliar a 16 GB RAM

Estimacion de necesidades de CPU

La prediccion de CPU depende de:

  • Crecimiento de la carga de trabajo (transacciones, solicitudes, etc.)
  • Cambios en el software (nuevas versiones pueden ser mas o menos eficientes)
  • Adicion de nuevos servicios al servidor

Metricas clave para proyectar:

  • Load average promedio y su tendencia
  • Porcentaje de uso de CPU y su evolucion
  • Tiempos de respuesta de aplicaciones

Herramientas para la prediccion

Uso de datos RRD para tendencias

Los archivos RRD (Round Robin Database) almacenados por collectd, MRTG o Cacti permiten generar graficos de tendencia a largo plazo.

# Generar grafico de tendencia con rrdtool
$ rrdtool graph tendencia.png \
  --start -30d \
  --end now \
  DEF:cpu=/var/lib/collectd/rrd/localhost/cpu-0/cpu-user.rrd:value:AVERAGE \
  LINE1:cpu#FF0000:"CPU Usage"

Analisis con hojas de calculo y scripts

Para predicciones simples, los datos exportados de sar o collectd se pueden analizar en hojas de calculo o con scripts:

# Exportar datos de sar a formato CSV para analisis
$ sadf -d /var/log/sysstat/sa15 -- -u > cpu_data.csv
 
# Script basico para calcular tendencia de uso de disco
$ df -h /home | awk 'NR==2{print strftime("%Y-%m-%d"), $3}' >> /var/log/disk_trend.log

Para el examen: sadf es el comando para convertir datos de sar a formatos legibles por otras herramientas (CSV, XML, etc.). Es la herramienta puente entre la monitorizacion y el analisis.

Nagios para capacidad

Aunque Nagios se centra en alertas, sus datos historicos pueden ser utiles para identificar tendencias:

  • Graficos de rendimiento de plugins
  • Historial de alertas que indican cuando se superaron umbrales
  • Planificacion basada en la frecuencia de alertas

Factores a considerar en la prediccion

Factores internos

  • Crecimiento organico: aumento natural de datos y usuarios
  • Nuevos proyectos: despliegue de nuevas aplicaciones o servicios
  • Cambios de version: actualizaciones que pueden cambiar los requisitos de recursos
  • Politicas de retencion: cuanto tiempo se mantienen logs, backups, etc.

Factores externos

  • Crecimiento del negocio: nuevos clientes, expansion de mercado
  • Estacionalidad: periodos de mayor actividad (fiestas, campanas, etc.)
  • Regulaciones: requerimientos de almacenamiento de datos por ley
  • Tendencias tecnologicas: nuevas tecnologias que cambian los patrones de uso

Estrategias de actuacion

Una vez identificada la tendencia, las acciones posibles incluyen:

RecursoAcciones a corto plazoAcciones a largo plazo
CPUOptimizar procesos, redistribuir cargaMigrar a hardware mas potente, escalado horizontal
MemoriaAjustar swap, optimizar aplicacionesAmpliar RAM, distribuir servicios
DiscoLimpiar archivos, comprimir datosAmpliar almacenamiento, implementar SAN/NAS
RedQoS, optimizar protocolosAmpliar ancho de banda, balanceo de carga

Escalado vertical vs. horizontal

  • Escalado vertical: aumentar recursos de la maquina existente (mas RAM, mejor CPU, mas disco)
  • Escalado horizontal: agregar mas maquinas y distribuir la carga

Para el examen: Debes entender que la prediccion no es solo sobre hardware. Optimizar software, ajustar configuraciones y redistribuir servicios son estrategias validas que deben considerarse antes de comprar hardware nuevo.

Herramientas de monitorizacion a largo plazo

collectd - Recopilador de metricas del sistema

collectd es un daemon que recopila metricas del sistema periodicamente y las almacena para analisis posterior.

# Archivo de configuracion principal
/etc/collectd/collectd.conf
# o en algunas distribuciones
/etc/collectd.conf

Arquitectura de plugins de collectd

TipoFuncionEjemplos
Read pluginsRecopilan datoscpu, memory, disk, interface, load, df
Write pluginsAlmacenan datosrrdtool, csv, network, write_graphite
Log pluginsRegistran eventoslogfile, syslog
Filter pluginsProcesan datosmatch_regex, target_scale
# Ejemplo de configuracion de collectd
LoadPlugin cpu
LoadPlugin memory
LoadPlugin disk
LoadPlugin interface
LoadPlugin df
LoadPlugin rrdtool
 
<Plugin rrdtool>
  DataDir "/var/lib/collectd/rrd"
  CacheFlush 120
  CacheTimeout 300
</Plugin>
 
<Plugin df>
  MountPoint "/home"
  MountPoint "/var"
  ReportByDevice false
  ReportInodes true
</Plugin>
 
<Plugin interface>
  Interface "eth0"
  IgnoreSelected false
</Plugin>

Para el examen: collectd usa una arquitectura de plugins. Los plugins de lectura recopilan datos, los de escritura los almacenan. El plugin rrdtool es el mas comun para almacenamiento. Los datos se guardan en /var/lib/collectd/rrd/.

MRTG (Multi Router Traffic Grapher)

MRTG genera graficos HTML de trafico de red a partir de datos SNMP:

# Configuracion principal
/etc/mrtg/mrtg.cfg
 
# Generar configuracion automatica desde un router SNMP
cfgmaker community@192.168.1.1 > /etc/mrtg/mrtg.cfg
 
# Ejecutar MRTG (normalmente via cron cada 5 minutos)
mrtg /etc/mrtg/mrtg.cfg
 
# Crear paginas indice
indexmaker /etc/mrtg/mrtg.cfg > /var/www/html/mrtg/index.html

Para el examen: MRTG se ejecuta periodicamente (cada 5 minutos via cron) y genera graficos HTML estaticos. Usa SNMP para obtener datos de red. cfgmaker genera la configuracion automaticamente a partir de un dispositivo SNMP.

Cacti - Interfaz web para RRDtool

Cacti es un frontend web para rrdtool que proporciona graficos interactivos y gestion de dispositivos SNMP:

  • Interfaz web para configurar que datos recopilar
  • Usa rrdtool como motor de almacenamiento y graficos
  • Soporta templates para facilitar la configuracion
  • Poller (recopilador) que se ejecuta via cron cada 5 minutos
  • Soporta SNMP y scripts personalizados como fuentes de datos

Nagios y capacidad

Nagios se centra en alertas, pero sus datos son utiles para prediccion:

# Configurar umbrales de alerta en Nagios
define service {
  use                 generic-service
  host_name           servidor-web
  service_description Disk Usage
  check_command       check_disk!20%!10%!/home
  # Alerta warning al 80%, critica al 90%
}
  • Los datos de performance de los plugins se pueden exportar a graficos
  • PNP4Nagios o Grafana pueden consumir estos datos para analisis de tendencias
  • El historial de alertas indica cuando se superaron umbrales (picos de uso)

SNMP para recopilacion de datos

SNMP (Simple Network Management Protocol) es fundamental para recopilar datos de dispositivos de red y servidores:

# Consultar uso de CPU via SNMP
snmpwalk -v2c -c community servidor .1.3.6.1.4.1.2021.11
 
# Consultar uso de disco
snmpwalk -v2c -c community servidor .1.3.6.1.4.1.2021.9
 
# Consultar interfaces de red
snmpwalk -v2c -c community servidor .1.3.6.1.2.1.2.2

Para el examen: SNMP es el protocolo estandar para recopilar metricas de dispositivos de red. MRTG y Cacti dependen de SNMP para obtener datos. Las versiones son SNMPv1 (sin seguridad), SNMPv2c (community strings), SNMPv3 (autenticacion y cifrado).

Documentacion y comunicacion

La planificacion de capacidad debe documentarse:

  • Informes periodicos: datos actuales, tendencias y predicciones
  • Umbrales de alerta: cuando actuar (tipicamente al 70-80% de uso)
  • Plan de accion: pasos a seguir cuando se alcanzan los umbrales
  • Presupuesto: estimacion de costes para las ampliaciones necesarias
  • Cronograma: fechas previstas para cada actuacion

La comunicacion de las necesidades a la direccion es parte esencial del rol del administrador de sistemas avanzado.

Trampas del examen

Errores comunes y distinciones criticas que LPI suele evaluar en este subtema:

  • sadf vs sar — sar muestra datos en formato legible para humanos; sadf convierte datos de sar a formatos procesables por otras herramientas (CSV, XML, JSON). El examen puede preguntar cual comando usar para exportar datos a una hoja de calculo
  • Prediccion sin datos historicos es imposible — sin herramientas como sar, collectd o RRD que recopilen datos a lo largo del tiempo, no se puede identificar tendencias. Un punto de datos aislado (df -h hoy) no basta
  • Escalado vertical vs horizontal — vertical es anadir mas recursos a la misma maquina (mas RAM, mejor CPU); horizontal es agregar mas maquinas. El examen puede describir un escenario y preguntar cual estrategia es adecuada
  • El umbral de accion es tipicamente 70-80%, no 100% — esperar a que un recurso se llene al 100% para actuar es un error critico. La planificacion de capacidad exige actuar con anticipacion, dejando margen de seguridad
  • Crecimiento lineal vs exponencial — un error frecuente es asumir crecimiento lineal cuando el patron es exponencial (por ejemplo, usuarios que se duplican cada trimestre). Usar la formula incorrecta da predicciones totalmente erroneas
  • collectd almacena en RRD, no en texto plano — los datos de collectd se guardan en archivos Round Robin Database en /var/lib/collectd/rrd/. No son archivos de texto que puedas leer directamente con cat
  • Estacionalidad puede enmascarar tendencias — si mides uso de CPU solo en diciembre (pico de trafico) y comparas con enero, pareceria que el uso baja. Debes comparar periodos equivalentes (diciembre con diciembre anterior)

Graph View