Planificar un Dedicated: CPU, RAM, discos y reserva

Dos ofertas con los mismos núcleos, RAM y disco pueden representar decisiones distintas. La diferencia apenas cabe en una línea: qué peticiones usan CPU, qué procesos comparten memoria y qué ocurre tras un fallo de disco o aplicación. Una solicitud útil de servidor dedicado empieza por esas preguntas.

Empiece por el trabajo que debe hacer el servidor

Enumere aplicaciones, motor de base de datos, tareas en segundo plano y conexiones externas. Incluya actividad normal y máxima, duración del procesamiento por lotes y crecimiento de datos. Una media diurna de CPU baja no impide que un informe nocturno presione memoria o almacenamiento.

Distinga trabajo CPU-bound, limitado por cálculo; memory-bound, sin espacio para datos activos; e I/O-bound, con esperas importantes de almacenamiento. En sistemas reales pueden coexistir varias limitaciones.

Elija un ciclo importante y defina la aceptación. Un proceso nocturno puede necesitar terminar antes de la jornada, o una acción del operador responder en un plazo acordado. Son ejemplos de cómo expresar el requisito. El plazo real y el error admisible dependen de su negocio; el nombre del servidor no los promete.

Indique si las cifras proceden de una aplicación existente o de una estimación nueva. La estimación necesita un piloto. Una carga existente exige un periodo representativo: el promedio de una hora tranquila puede ocultar el pico diario. Guarde fechas y condiciones junto al resultado.

CPU: mire más allá del promedio

Considere generación de procesador, rendimiento por núcleo, paralelismo y licencias. Más núcleos no aceleran automáticamente una tarea secuencial. Cada petición no ocupa un núcleo permanente, por lo que no convierta visitas directamente en número de cores.

Comience con mediciones del workload real. La información de presión de Linux, cuando está disponible, ayuda a distinguir esperas de CPU, memoria e I/O, pero depende de kernel y configuración. Una métrica aislada no diagnostica toda la causa.

Un porcentaje medio de CPU bajo no implica que todos los procesos estén cómodos. Un hilo importante puede saturarse con otros núcleos libres. Una petición lenta también puede esperar almacenamiento o una API externa. Relacione operación, CPU y señales de espera; ampliar por una sola gráfica es una suposición costosa.

La RAM es un presupuesto compartido

Incluya sistema operativo, procesos, base de datos, caché y herramientas de gestión. Estime por separado el máximo por proceso y cuántos trabajan simultáneamente. Un único ajuste de base de datos no representa necesariamente toda su memoria.

Suponga un workload ficticio que necesita 6 GiB de memoria activa. Para dejar libre el 25% de la capacidad total, calcule 6 / (1 - 0.25) = 8 GiB. Añadir simplemente un 25% a seis deja una reserva diferente. El pico real debe medirse por separado; la operación aritmética no es un benchmark.

No cuente dos veces la misma memoria. El límite de un contenedor puede incluir la caché de la base de datos o cubrir solo la aplicación. Relacione los picos de varios servicios con ventanas temporales reales. Sumar máximos independientes puede sobredimensionar; ignorarlos puede quedarse corto.

Asocie el margen a una causa: demanda estacional, un proceso batch o procesos adicionales durante una publicación. Un porcentaje universal por si acaso no explica cuándo se agotará la capacidad. Anote la señal que provocará una revisión y el tiempo del siguiente paso.

El almacenamiento también plantea una recuperación

La suma de las etiquetas de disco no equivale al espacio para aplicaciones. Por ejemplo, un espejo de dos unidades de 960 GB ofrece nominalmente 960 GB para datos antes de sistema de archivos, OS y otros gastos. Confirme el espacio utilizable del diseño propuesto.

RAID no sustituye al backup. Un borrado accidental o corrupción puede afectar también a los datos reflejados. Ubicación, retención y recuperación del backup son requisitos independientes. Una instantánea tampoco demuestra automáticamente la existencia de una copia independiente.

Defina el perfil de I/O: transferencias secuenciales grandes, operaciones aleatorias pequeñas y latencia representan necesidades distintas. La etiqueta NVMe no garantiza una respuesta concreta de su aplicación.

Escriba el ejemplo de almacenamiento con unidades. Dos discos hipotéticos de 960 GB en espejo guardan dos copias de los datos; no ofrecen 1920 GB utilizables. Sistema de archivos, unidades y reservas necesitan aclaración. Agrupar RAID y backup en una línea dificulta comparar.

Para la recuperación, determine la pérdida de datos tolerable y el tiempo de retorno del servicio. Distinga la prueba realizada: un archivo, una base de datos o toda la aplicación. Tener una copia y recuperar un servicio operativo son resultados diferentes. Ubicación, aislamiento y retención requieren confirmación propia.

Compare ofertas en el mismo lenguaje

Compare dos casos ficticios: informes con pocos usuarios simultáneos y cálculos intensivos, y una tienda con muchas peticiones paralelas y datos cambiantes. Igual capacidad de disco no implica iguales necesidades de CPU, RAM e I/O.

Añada el coste de operar el servidor

Revise activación, duración de contrato, licencias OS/panel, gestión, backup, IP y condiciones de red. Utilice la página actual de SERVER1 y la oferta concreta. No presuponga precios permanentes ni disponibilidad de cualquier configuración.

Describa la gestión con acciones. ¿Quién actualiza el sistema, revisa alertas, cambia la configuración y atiende un incidente? Administrado es solo un título hasta confirmar el alcance concreto. Aclare las licencias, servicios externos y trabajos puntuales incluidos.

En la aceptación, no revise únicamente la lista de hardware. Concilie la configuración, guarde una observación inicial y pruebe la aplicación representativa. La migración es otro cambio con sincronización, retorno y verificación del recorrido del usuario. Preparar el servidor y terminar la migración son hitos distintos.

Un brief para una conversación técnica útil

La nota siguiente inicia una consulta útil. No todos los campos necesitan una cifra. Si un valor es desconocido, márquelo para medir e indique de dónde podría obtenerse. La incertidumbre visible ayuda más a una oferta adecuada que una precisión inventada.

Finalidad: [aplicación y operación relevante]
Periodo observado: [fechas y pico]
CPU/RAM/I/O: [medido o pendiente]
Datos: [volumen, crecimiento y capacidad utilizable]
Recuperación: [pérdida y tiempo aceptables]
Gestión: [responsables y alcance por confirmar]
Aceptación: [escenario y condición de decisión]

Use el brief para comparar las ofertas vigentes de servidores dedicados. Si necesita ayuda operativa, detalle el trabajo al consultar Dedicated administrado. Aclarar capacidad y alcance juntos reduce compras basadas en suposiciones.

Para las primeras observaciones: Monitoring de Linux VPS: cómo interpretar CPU, RAM, Disk y Load.

Referencias técnicas de presión de recursos y memoria: Linux kernel - Pressure Stall Information; PostgreSQL - Resource consumption.