Migrar una base de datos a infraestructura cloud rara vez es el ejercicio neutro en rendimiento que sugiere el diagrama de arquitectura. Los equipos que han pasado años ajustando almacenamiento on-premises, ya sea NVMe de conexión directa o una SAN bien conocida, aterrizan en volúmenes en bloque genéricos de cloud y notan de inmediato la diferencia: la latencia sube, la consistencia de IOPS se degrada bajo carga y los controles de ajuste en los que confiaban se comportan de manera distinta o desaparecen por completo. El problema no es el almacenamiento cloud en sí. Es que la mayoría de los consejos sobre almacenamiento en bloque cloud están escritos para la carga de trabajo mediana, no para la base de datos OLTP que ejecuta 50.000 transacciones por minuto con un presupuesto de latencia de 2 ms.
Este artículo cubre los controles que realmente marcan la diferencia: selección del protocolo de almacenamiento, configuración del planificador de I/O de Linux y ajuste de la profundidad de cola. Nada de esto es exótico. Todo se omite en las guías de migración genéricas, y ese vacío es donde vive la mayoría de los problemas de rendimiento de almacenamiento en bases de datos.
Por qué la latencia del almacenamiento en bloque cloud sorprende a los equipos de bases de datos
El almacenamiento de bases de datos on-premises suele ajustarse en torno a rutas predecibles y de baja latencia. Una unidad NVMe conectada localmente completa operaciones de I/O en decenas de microsegundos. Los protocolos SAN heredados como iSCSI o FCP añaden sobrecarga de software y red que puede llevar cada operación de I/O a cientos de microsegundos, pero los equipos han aprendido a tenerlo en cuenta. Los volúmenes en bloque cloud introducen una tercera categoría: almacenamiento conectado en red con sobrecarga variable que depende del hipervisor, el backend de almacenamiento y lo que más esté ejecutándose en el tejido compartido en ese momento.
Las cargas de trabajo de bases de datos son especialmente sensibles a esto porque sus requisitos se agrupan en torno a dos aspectos: consistencia de IOPS y predictibilidad de latencia. Una ráfaga de lecturas aleatorias de 4K a profundidad de cola 1 revela el verdadero piso de una ruta de almacenamiento. Una carga de trabajo mixta sostenida de lectura y escritura a una concurrencia realista revela si ese piso se mantiene. La infraestructura compartida puede superar la primera prueba y fallar la segunda de maneras genuinamente difíciles de predecir sin benchmarking específico de la carga de trabajo antes de la migración.
La capa de protocolo: NVMe no es solo una promesa de marketing
La elección del protocolo de almacenamiento establece un techo duro sobre lo que el ajuste puede lograr. El perfil de latencia de NVMe, de 20 a 100 microsegundos para unidades empresariales, no es una mejora marginal respecto a los SSD SATA (80 a 200 µs) ni siquiera respecto a los mejores SSD SAS (50 a 200 µs). A las profundidades de cola y niveles de concurrencia típicos de las bases de datos OLTP, la brecha se amplifica. Los SSD PCIe/NVMe empresariales entregan aproximadamente 1.400.000 IOPS de lectura en benchmarks controlados, unas 16 veces más que los SSD SATA empresariales con 85.000 IOPS de lectura. Gen4 NVMe alcanza un ancho de banda de lectura secuencial superior a 7 GB/s; Gen5 lo duplica de nuevo.
La razón arquitectónica importa tanto como la cifra principal. AHCI, la interfaz de comandos subyacente a SATA, soporta una única cola de 32 comandos. NVMe soporta hasta 65.535 colas de 65.535 comandos cada una. Para una base de datos con muchas sesiones concurrentes, esto no es una ventaja teórica. Es la diferencia entre un I/O serializado que acumula latencia bajo carga y un I/O paralelo que escala con la concurrencia.
Si tu protocolo de almacenamiento no puede seguir el ritmo del modelo de concurrencia de la base de datos, ningún ajuste de planificador o profundidad de cola lo compensará. El techo se establece en la capa de protocolo.
Cuando el almacenamiento en bloque se entrega a través de la red, la elección del protocolo vuelve a importar. NVMe over Fabrics (NVMe-oF) preserva gran parte de la ventaja de latencia del NVMe conectado localmente al extender el conjunto de comandos NVMe a través de un tejido de red, en lugar de traducirlo a semántica iSCSI o FCP y pagar la sobrecarga de esa traducción en cada operación de I/O. Los benchmarks muestran consistentemente que NVMe-oF entrega significativamente más IOPS por núcleo de CPU que iSCSI, lo que importa cuando el rendimiento del almacenamiento compite con la CPU de la base de datos por los mismos recursos del host.
Planificador de I/O de Linux: el valor predeterminado es correcto, hasta que no lo es
El kernel de Linux selecciona un planificador de I/O según el tipo de dispositivo. Para dispositivos NVMe, el valor predeterminado es none, lo que significa que las solicitudes se pasan directamente al controlador sin reordenamiento. Esto es intencional. Si el dispositivo ya gestiona la optimización de solicitudes en firmware, añadir una capa de planificador por software consume ciclos de CPU sin mejorar la latencia. La misma lógica se aplica a las VM invitadas que usan virtio-blk: el host ya está planificando, y hacerlo dos veces desperdicia trabajo.
El caso de mq-deadline es más acotado pero real. Es apropiado para almacenamiento rotacional, para cargas de trabajo donde prevenir la inanición de I/O importa más que minimizar la latencia promedio, y para patrones mixtos de lectura y escritura donde las solicitudes de escritura necesitan una ventana de servicio garantizada. Con mq-deadline, las solicitudes de lectura tienen un plazo de 500 ms y las de escritura de 5 segundos; las solicitudes que se acercan a su plazo se promueven independientemente de su posición en la cola. Oracle recomienda explícitamente none para NVMe y SSD, y mq-deadline para almacenamiento rotacional, en Oracle Linux 8 y versiones posteriores, RHEL 8 y versiones posteriores, y SUSE Linux Enterprise Server 15 y versiones posteriores.
El error práctico es dejar mq-deadline activo en volúmenes NVMe porque estaba configurado para el array HDD on-premises y nadie lo cambió durante la migración. En NVMe, añade latencia sin aportar valor.
Profundidad de cola: el control de ajuste con las compensaciones más marcadas
La profundidad de cola controla cuántas operaciones de I/O están en vuelo simultáneamente. Configurarla demasiado baja deja ancho de banda del dispositivo sin usar; configurarla demasiado alta introduce contención y amplifica el jitter de latencia, especialmente durante microráfagas. Para cargas de trabajo de bases de datos, la compensación es asimétrica: un breve pico de latencia a alta profundidad de cola puede causar timeouts de transacciones que un techo de IOPS ligeramente inferior no causaría.
Las profundidades de cola entre 32 y 128, con tamaños de bloque entre 4 KiB y 16 KiB, cubren el rango que la mayoría de los equipos de bases de datos debería evaluar primero. El valor correcto depende del modelo de concurrencia de la carga de trabajo y del paralelismo interno del backend de almacenamiento. Una buena secuencia de benchmark ejecuta la misma carga de trabajo a profundidades de cola de 1, 4, 8, 16, 32, 64 y 128, y luego grafica tanto los IOPS como la latencia promedio. El punto de inflexión donde la latencia empieza a crecer más rápido que los IOPS es el techo práctico para esa carga de trabajo en esa ruta de almacenamiento.
Una profundidad de cola excesiva tiene un coste secundario: eleva la sobrecarga de CPU por segundo y amplía la distribución de latencia. Para una base de datos con SLOs de latencia estrictos, una latencia p99 que se duplica a profundidad de cola 128 respecto a profundidad de cola 32 es un problema operativo real, aunque la latencia promedio sea aceptable.
Almacenamiento en bloque respaldado por bare metal y la cuestión de la sobrecarga del hipervisor
Una variable que los consejos genéricos de cloud pasan por alto sistemáticamente es la sobrecarga del hipervisor en la ruta de almacenamiento. Cada capa de virtualización entre el proceso de la base de datos y la unidad NVMe física añade latencia y, más importante, añade varianza. Para cargas de trabajo OLTP sensibles a la latencia, la consistencia de la ruta de almacenamiento importa tanto como su rendimiento máximo.
Aquí es donde el almacenamiento en bloque respaldado por bare metal cambia el cálculo. En MUC1, nuestro datacenter de Múnich, operamos infraestructura bare metal precisamente porque las cargas de trabajo financieras e industriales concentradas en el mercado DACH tienen requisitos de latencia estrictos que las capas de hipervisor compartidas no pueden satisfacer de forma fiable. El almacenamiento en bloque respaldado por NVMe conectado localmente en bare metal elimina por completo la variable de sobrecarga del hipervisor, lo que significa que el trabajo de ajuste descrito anteriormente opera sobre una línea base estable en lugar de un objetivo en movimiento.
Benchmarking antes de migrar, no después
La secuencia importa. El modo de fallo habitual es migrar primero, chocar con un muro de rendimiento y luego intentar ajustar contra un sistema en producción bajo presión. La secuencia correcta es establecer la línea base on-premises con una herramienta como fio a profundidades de cola y tamaños de bloque realistas, replicar ese perfil de carga de trabajo contra el almacenamiento cloud de destino y comparar los resultados antes de mover cualquier tráfico de producción.
Números específicos a capturar: IOPS de lectura aleatoria de 4K a profundidad de cola 1 (el piso de latencia), IOPS de lectura aleatoria de 4K al número esperado de sesiones concurrentes (el techo de rendimiento), latencia p99 a ambas profundidades de cola y la distribución de latencia bajo una carga mixta sostenida de lectura y escritura. Si la ruta de almacenamiento cloud no puede igualar la línea base on-premises en estas métricas en una prueba controlada, tampoco lo hará en producción.
El ajuste de I/O en almacenamiento en bloque no es una tarea de limpieza post-migración. Es un requisito previo para saber si la migración es viable en absoluto.
