NVMe frente a SSD SATA para VPS: rendimiento, cargas de trabajo y costo

Dos planes pueden indicar la misma cantidad de vCPU y de memoria, y sin embargo uno termina una migración de base de datos en minutos mientras el otro se atasca durante una hora. La diferencia suele estar en la ruta de almacenamiento: unidades NVMe conectadas por PCIe frente a SSD SATA o SAS detrás de una controladora tradicional.

Esta guía explica qué diferencia realmente a ambos, qué cargas de trabajo se benefician de NVMe y cuáles no, cómo medir un servidor usted mismo con fio antes de comprometerse, y por qué las cuotas de transferencia y la ubicación forman parte de la misma decisión.

Qué cambia realmente: interfaz, protocolo y colas

La diferencia está en cómo se comunica la unidad con la CPU. Los SSD SATA usan el protocolo AHCI, diseñado para discos giratorios, sobre un enlace que alcanza como máximo 6 Gbps, lo que en la práctica significa unos 550 MB/s de throughput secuencial. SAS eleva el enlace a 12 Gbps y añade funciones empresariales como el doble puerto, pero sigue pasando por un adaptador de bus de host o una controladora RAID.

Las unidades NVMe se conectan directamente a líneas PCIe. La diferencia más importante para los servidores son las colas: AHCI ofrece una sola cola de comandos con 32 entradas, mientras que NVMe admite hasta 64K colas con hasta 64K comandos cada una.

En un VPS, el sistema invitado no ve directamente la unidad física. Una buena configuración del host conserva la mayor parte de la ventaja de NVMe. Una mala configuración, una sobreasignación excesiva o límites de E/S agresivos pueden anularla.

IOPS, latencia y profundidad de cola, explicadas para compradores

Tres cifras describen el rendimiento del almacenamiento, y están relacionadas. Las IOPS son el número de operaciones de lectura o escritura completadas por segundo, normalmente medidas con bloques pequeños de 4 KB. La latencia es lo que tarda una sola operación. La profundidad de cola es la cantidad de operaciones pendientes al mismo tiempo.

Estas magnitudes se relacionan mediante una regla sencilla: las IOPS son aproximadamente la profundidad de cola dividida entre la latencia. Una unidad que responde en 100 microsegundos con una profundidad de cola de 1 ofrece unas 10.000 IOPS. Las cifras de IOPS destacadas casi siempre se publican con una profundidad de cola alta, lo que favorece a las unidades en condiciones que muchas aplicaciones nunca generan.

Una base de datos transaccional que confirma una transacción a la vez, esperando cada fsync, trabaja con una profundidad de cola cercana a 1. En ese caso la latencia importa más que las IOPS máximas. NVMe suele reducir la latencia del dispositivo en comparación con SATA, y la ruta de software más corta elimina sobrecarga adicional, por lo que la mejora se nota incluso cuando la aplicación no envía muchas solicitudes en paralelo.

La latencia de cola merece la mayor atención. Al comparar servidores, observe la latencia de finalización en los percentiles 99 y 99.9.

Cargas de trabajo que se benefician de NVMe

NVMe compensa cuando la aplicación está limitada por la latencia del almacenamiento o por muchas operaciones pequeñas concurrentes. Los casos más claros son:

• Bases de datos relacionales. PostgreSQL, MySQL y motores similares escriben en un log en cada commit y leen páginas aleatorias cuando el conjunto de trabajo supera la memoria. Una menor latencia de escritura eleva la tasa de commits, y unas lecturas aleatorias más rápidas acortan las consultas que no encuentran los datos en el buffer cache.
• Índices de búsqueda y de analítica. Elasticsearch, OpenSearch y motores similares fusionan segmentos, refrescan índices y leen muchos archivos pequeños. NVMe acorta el tiempo de indexación y mantiene estable la latencia de las consultas durante las fusiones.
• Servidores de compilación y de CI. Compilar bases de código grandes, resolver dependencias y ejecutar suites de pruebas generan miles de lecturas y escrituras de archivos pequeños. Las compilaciones que en teoría están limitadas por la CPU a menudo resultan estar esperando al almacenamiento.
• Almacenes clave-valor con persistencia. Los sistemas que escriben snapshots o logs de solo anexado en disco se benefician de vaciados rápidos, que reducen la pausa que perciben los usuarios durante la persistencia.
• Hosts de contenedores y de virtualización. Descargar imágenes, iniciar muchos contenedores y ejecutar varios servicios con mucha actividad en una sola máquina multiplica la concurrencia de E/S, que es justo donde ayudan las colas de NVMe.
• Trabajos de procesamiento de datos. Los pasos de ETL que ordenan, vuelcan a disco o redistribuyen archivos intermedios terminan antes cuando el almacenamiento temporal es NVMe.

Cargas de trabajo en las que basta con SSD SATA o SAS

Muchas cargas de trabajo apenas notan diferencia, o ninguna, porque el almacenamiento no es su cuello de botella.

• Sitios web con una caché eficaz. Un sitio de contenido servido mayormente desde memoria, una caché de páginas o una CDN lee muy poco del disco una vez que se ha calentado.
• Servidores de aplicación sin estado. Las capas de API y web que guardan los datos en una base de datos aparte dedican su tiempo a CPU y red.
• Entrega con uso intensivo de ancho de banda. La distribución de archivos, los orígenes de streaming y los mirrors de descarga leen archivos grandes de forma secuencial. Un SSD SATA de unos 550 MB/s ya supera lo que puede transportar un puerto de 1 Gbps (unos 125 MB/s).
• Destinos de respaldo y archivos. Las escrituras secuenciales de objetos grandes priorizan la capacidad por dólar sobre la latencia.
• Bases de datos pequeñas que caben en memoria. Si todo el conjunto de trabajo reside en la RAM, las lecturas rara vez tocan el disco, y unas tasas de commit moderadas quedan holgadamente dentro de los límites de SATA.
• Herramientas internas con poco tráfico. Wikis, sistemas de tickets y paneles de monitoreo con unas pocas decenas de usuarios rara vez generan una presión de E/S significativa.

Aquí, el presupuesto suele rendir más en capacidad de SSD SATA o SAS empresarial, memoria o ancho de banda ilimitado.

Cómo medir con fio antes de comprometerse

fio es la herramienta estándar de código abierto para benchmarks de almacenamiento en Linux y está disponible en los repositorios de paquetes de todas las distribuciones principales. Ejecútela en un servidor de prueba o recién aprovisionado, sobre un archivo de prueba en el mismo sistema de archivos que usará su aplicación, nunca sobre un dispositivo sin formato que contenga datos.

Empiece con una prueba de lectura aleatoria con concurrencia moderada, que se aproxima a una base de datos o un nodo de búsqueda con mucha actividad: fio --name=randread --filename=/var/tmp/fiotest --size=4G --rw=randread --bs=4k --ioengine=libaio --direct=1 --iodepth=32 --numjobs=4 --runtime=60 --time_based --group_reporting.

Después, ejecute una prueba que reproduzca los commits de una base de datos: fio --name=commit --filename=/var/tmp/fiotest --size=1G --rw=randwrite --bs=4k --ioengine=libaio --direct=1 --iodepth=1 --numjobs=1 --fsync=1 --runtime=60 --time_based.

Por último, ejecute una prueba secuencial con --rw=read y --bs=1M para confirmar el throughput de los respaldos y del trabajo con archivos grandes. Al leer los resultados, registre los IOPS, el ancho de banda y los percentiles de latencia de finalización (clat) en p50, p99 y p99.9. En infraestructura compartida, la consistencia de los resultados entre ejecuciones es tan importante como la cifra máxima, porque muestra lo bien que el host aísla a los vecinos.

Elimine después el archivo de prueba. Evite benchmarks pesados en producción en horario laboral: compiten con el tráfico real.

Cuotas de transferencia, puertos con tráfico ilimitado y costo total

Un plan solo es barato si sus condiciones de transferencia se ajustan a la cantidad de datos que usted realmente mueve.

Un puerto de 1 Gbps mueve unos 125 MB por segundo, aproximadamente 10.8 TB al día o unos 324 TB al mes a plena carga. Una cuota mensual de 3 TB corresponde a un promedio sostenido de solo unos 9 Mbps, y una de 16 TB a unos 49 Mbps.

Los planes medidos con una cuota de transferencia se adaptan a cargas de trabajo en las que el rendimiento del almacenamiento es la prioridad y el tráfico es moderado y predecible. Compruebe qué ocurre cuando se supera la cuota: cargo por cada terabyte excedente, reducción a una velocidad menor o un cambio de plan obligatorio. Los planes con tráfico ilimitado cobran un precio fijo por el puerto y se adaptan a cargas de trabajo con un tráfico de salida intenso o impredecible. Confirme la velocidad del puerto, si es dedicado o compartido, y cualquier condición de uso razonable.

Estime el egreso mensual a partir de los logs actuales o de los datos de facturación del proveedor, añada margen para el crecimiento y para el tráfico de respaldo que sale del servidor, y compare el costo mensual total, incluidos los excedentes, entre las opciones. A veces el diseño correcto divide la carga de trabajo: NVMe para la capa de base de datos con una cuota modesta, y servidores SSD con tráfico ilimitado para la capa de entrega.

Cómo elegir la ubicación de un VPS

La ubicación afecta a la latencia, al cumplimiento normativo y al costo. La luz en la fibra óptica recorre unos 200 km por milisegundo, por lo que cada 100 km de fibra añaden cerca de 1 ms de tiempo de ida y vuelta antes de cualquier sobrecarga de enrutamiento. Las rutas reales son más largas que las líneas rectas, y por eso un servidor en otro continente suele añadir entre 100 y 250 ms por cada ida y vuelta.

• Ubique los servidores cerca de los usuarios. Mida el tiempo de ida y vuelta desde las regiones donde se origina la mayor parte del tráfico, con ping, mtr o monitoreo sintético.
• Mantenga juntos los componentes muy comunicativos. Un servidor de aplicación y su base de datos deberían compartir ubicación. El almacenamiento NVMe rápido se desperdicia si cada consulta cruza un océano.
• Verifique la residencia de los datos. Las regulaciones y los contratos con clientes pueden exigir que los datos permanezcan en un país específico. Confirme dónde se almacenan el servidor, sus respaldos y cualquier réplica.
• Planifique ante fallos regionales. Una segunda ubicación para respaldos o un standby en caliente protege frente a una caída en una instalación.
• Compare precios regionales y condiciones de transferencia. La misma configuración puede tener cuotas y costos distintos en regiones distintas.

Tabla de decisión y lista de verificación

Tabla de decisión: cada fila asocia un perfil de carga con un tipo de almacenamiento y un modelo de transferencia.

• Base de datos transaccional con un conjunto de trabajo mayor que la memoria. Elija NVMe. Una cuota de tráfico medido suele ser suficiente, ya que el tráfico de la base de datos se mantiene mayormente interno.
• Clúster de búsqueda o índice de analítica. Elija NVMe con memoria suficiente para la caché del sistema de archivos. Las necesidades de transferencia suelen ser moderadas.
• Servidor de compilación o de CI. Elija NVMe. Incluya en la estimación de transferencia las descargas de dependencias y artefactos.
• Sitio web con caché o capa de API sin estado. Basta con SSD SATA o SAS. Elija tráfico ilimitado si el tráfico público es grande o presenta picos.
• Entrega de archivos, origen de streaming o mirror. SSD de alta capacidad y un puerto con tráfico ilimitado. NVMe aporta poco, porque la red limita el throughput.
• Destino de respaldo o archivo. La capacidad es lo primero. SSD o almacenamiento en bloque en red, dimensionado para la retención, con condiciones de transferencia que cubran el tráfico de restauración.
• Carga mixta en una sola máquina. Elija NVMe para la capa de datos, o reparta las capas entre servidores para que cada una obtenga el modelo de almacenamiento y de transferencia que necesita.

Antes de firmar, recorra esta lista de verificación:

• Use el monitoreo actual para hallar el límite: latencia, throughput, CPU o red.
• Ejecute pruebas fio de lectura aleatoria, fsync y secuenciales; registre la latencia p99 y p99.9.
• Repita las pruebas a distintas horas para comprobar hosts compartidos.
• Estime el egreso mensual con los logs más el crecimiento y compárelo con la cuota o la velocidad del puerto.
• Confirme por escrito las condiciones de excedentes, limitación de velocidad o uso razonable.
• Mida el tiempo de ida y vuelta desde sus regiones clave hasta cada sitio.
• Confirme el país de los datos, respaldos y réplicas.
• Verifique hipervisor, interfaz de disco y límites de E/S publicados por plan.
• Planifique respaldos en una segunda ubicación y pruebe una restauración.

Cómo puede ayudar Vonahost

La línea VPS NVMe funciona sobre KVM con hasta 8 vCPU, 32 GB de memoria y 500 GB de NVMe, con 3 a 16 TB de transferencia mensual, en la región que usted elija. La línea VPS SSD utiliza SSD empresarial con hasta 12 núcleos, 64 GB de memoria y 800 GB de almacenamiento, tráfico ilimitado y Linux o Windows, en la región que usted elija. Para cargas de trabajo que superan un VPS, los servidores dedicados single-tenant ofrecen NVMe local (2 x 960 GB) con un puerto dedicado de 1 Gbps y tráfico ilimitado.

Cada propuesta indica la configuración, la ubicación, las responsabilidades y el precio mensual en dólares estadounidenses, y usted elige el país de cada servidor.