Las opiniones reflejadas en este Blog son personales. La información se proporciona "como está" sin garantías de ninguna clase, y no otorga ningún derecho.
Hola
Existe abundante información acerca del impacto que tiene este tema en el rendimiento de las cargas de trabajo que hacen un uso intensivo del sistema de almacenamiento. Si indagáis un poco es frecuente encontrar datos que justifican ganancias/pérdidas de rendimiento de hasta el 30-40% por el hecho de tener las particiones alineadas o desalineadas en sistemas que usan “arrays” de discos que usen diferentes niveles de tolerancia a fallos.
Los sistemas de almacenamiento modernos son lo suficientemente complejos como para que el viejo modelos para representar a los discos basado en Cilindros, Cabezas y Sectores (CHS), o el esquema LBA para direccionar la información que almacenan, se puedan considerar una mera simplificación conceptual. Sin embargo, estos tres factores tienen especial relevancia en el fenómeno del alineamiento/desalineamiento de las particiones de un array de discos.
El alineamiento de las particiones se basa en buscar una buena combinación de los tres parámetros anteriores, de manera que una cierta operación de lectura/escritura no suponga tener que ir a buscar los datos a más de un disco de los que conforman el volumen. Si para ciertas peticiones tenemos que acabar leyendo o escribiendo en diferentes discos, la acumulación de las mismas puede conllevar una pérdida de rendimiento muy significativa. Para evitar esto, es importante que las siguientes relaciones den como resultado un número entero:
Esto se entiende muy bien con un el siguiente gráfico. En el vamos a suponer que la Stripe Size Unit es 64 KB y analizaremos cinco casos en los que usaremos diferentes Partition Offsets y tamaños de cluster. Lamentablemente no se puede pintar bien a escala, por lo que los guioncillos intermedios representan que la gráfica se “estira” por ellos. Cada sector representa 512 Bytes.
La buena noticia es que el desalineamiento es fácil de detectar, y también es fácil crear particiones alineadas. La mala es que corregir la situación a posteriori supone reparticionar y formatear de nuevo.
Comprobando si las particiones están o no alineadas
Habida cuenta de que conocemos el Stripe Set Unit que utiliza nuestro almacenamiento, el Partition Offset y el tamaño de cluster los podemos obtener así:
El comando DISKPART también muestra el Offset de las particiones, sin embargo no es de fiar, porque lo da en KB y redondea. En el primer ejemplo de la gráfica anterior nos hubiera engañado miserablemente mostrando 32 KB.
Si nos salen las cuentas, estupendo. Si no, nos espera la tediosa tarea de rehacer nuestras particiones, con lo que eso supone en lo tocante al salvaguardado de los datos y su disponibilidad durante el proceso.
Generando particiones alineadas
Una vez creada la partición, la formatearemos usando el tamaño de cluster deseado, pero recordando que la relación Stripe Unit/Allocation Unit debe dar también un entero. Sin embargo es muy improbable que esto no sea así.
Eligiendo sabiamente los valores de la Stripe Set Unit y Allocation Unit antes de ponerse manos a la obra
Desafortunadamente, aquí no podemos hablar de a existencia de una regla general. Estos valores deben ser elegidos en función de la naturaleza de la carga de trabajo, teniendo en cuenta el balance entre lecturas y escritoras, si serán secuenciales o aleatorias, en bloques de qué tamaño se escribirá/leerá la información, etc., y también de como se comportan las cachés y cada almacenamiento en particular. Por eso es muy frecuente encontrar guías específicas de cada fabricante para las cargas de trabajo más frecuentes.
Así es que antes de hacer nada “sabiamente” no nos queda otra que leernos esto para empezar:
para posteriormente bucear entre los whitepapers de los fabricantes de nuestras cabinas.
Vamos a dejarlo aquí por ahora. Supongo que los que hayáis llegado a leer hasta aquí os estaréis preguntando cómo aplica todo esto a entornos virtualizados, tanto a nivel de host como de máquina virtual. Es de cajón que las LUN donde se almacenen las VMs, o los discos pass-through es importante que estén alienados. Pero, ¿y las propias particiones de las VMs?. ¿Que tamaños de cluster y Stripe Unit Set son adecuadas?. Lo veremos en otro post.
CREDITOS:
REFERENCIAS:
David Cervigón
¡Gracias David! Prometo (con los dedos cruzados) no volver a darte la coña a altas horas...
Hola, enhorabuena por el artículo. Una duda, cuando hablas de la relación entre
Partition Offset / Stripe Size Unit
Stripe Size Unit / Allocation Unit
no acabo de entenderlo porque facilmente el Stripe Size es menor que el Allocation Unit, por ejemplo en nuestros servidores el Stripe Size máximo es 256, si queremos poner un allocation Unit de 512 para que el sistema nos permita compresión ya no sale un número entero. Muchas gracias.
Perdón, retiro mi absurda pregunta, me he hecho un lio yo solo. Gracias y enhorabuena de nuevo!!!