A los que nos movemos por la comunidad de Nutanix en España nos encanta presumir de la magia del "one-click" y de lo bonita que es la resiliencia distribuida. Pero cuando la gente de bases de datos viene con la antorcha encendida porque su SQL o su Oracle "va lento", la consola visual no los va a calmar.
Para entender por qué Nutanix puede mirar de tú a tú (y a veces despeinar) a las cabinas SAN de fibra más caras del mercado, hay que mancharse las manos y mirar qué pasa bajo el capó de Stargate y la evolución del Data Path. ¡Venga, al lio!
Durante años, el viaje de un dato en un entorno virtualizado parecía una yincana burocrática: saltos, paradas y cambios de contexto entre el espacio de usuario (donde vive la CVM) y el espacio de kernel del sistema operativo. Mientras usábamos discos mecánicos o SSDs "normalitos", el kernel disimulaba bien. Pero cuando llegaron las memorias NVMe, el propio sistema operativo se convirtió en ese coche que va delante de ti a 10 km/h en una via de 50.
Relacionado con esto, hay un mito sobre la hiperconvergencia que resiste como los bulos en twitter: "Sí, HCI está muy bien para muchas VMs pequeñas, pero si le metes un disco gigante a un SQL Server, se ahoga". Y en parte tenían su punto: antes, un único hilo controlador en la CVM gestionaba todas las peticiones de ese vDisk. Si la VM era un "monstruo", el hilo echaba humo.
Pero eso se acabó con vDisk Sharding (AOS 6.1). En vez de colar todo el tráfico por una puerta de un solo carril, el sharding trocea y reparte las peticiones entre varios hilos secundarios (shards). Para el hipervisor, el disco sigue siendo un único bloque sólido, pero por detrás hay un equipo entero trabajando en paralelo. Así es como logramos que aplicaciones legacy —diseñadas cuando el almacenamiento distribuido sonaba a ciencia ficción— saquen millones de IOPS con latencias que rozan el absurdo (sub-milisegundo).
Tener discos tan rápidos de nada sirve si la red se pasa el día chismorreando sobre dónde está cada dato. Para evitar que las escrituras aleatorias saturen el inventario, AOS usa Autonomous Extent Store (AES), que se salta el paso intermedio del OpLog cuando toca escribir.
Al gestionar los metadatos de forma puramente local en el nodo donde vive la VM, reducimos hasta un 75% el "ruido" de red y nos ahorramos un 40% de escrituras innecesarias en disco. En clústeres grandes, esto es la diferencia entre una red colapsada por el tráfico administrativo y un entorno donde los datos vuelan.
Si te toca diseñar el hogar para cargas donde cada microsegundo duele (SAP HANA, grandes instancias de Oracle o SQL Server), esta es tu Santísima Trinidad:
- Blockstore + SPDK: Para no hacerle perder el tiempo a tus discos NVMe.
- vDisk Sharding: Para que tus discos virtuales gigantescos no tengan crisis de ansiedad.
- AES: Para que la red trabaje para tus datos, no para los metadatos.
¿Has probado ya a medir la diferencia con vDisk Sharding activado en tus bases de datos más pesadas? ¡Pásate por el Foro Técnico de la comunidad de Nutanix en español o cuéntanos tu experiencia en el grupo de WhatsApp antes de que alguien vuelva a decir que prefiere una SAN de hace diez años!