Currently Being Moderated
jamarmu

Cariño, he desalineado a los niños

Posted by jamarmu in El Blog de Jamarmu on Apr 19, 2012 1:52:30 AM

Todos los sistemas de almacenamiento funcionan con bloques de datos, que son la unidad mínima de información que pueden leer y escribir en cada operación. Este tamaño, que algunos se empeñan en esconder bajo páginas y páginas de manuales en pdf, es un valor que es muy importante conocer cuando se planifican e implementan sistemas de almacenamiento. En el caso de NetApp, el tamaño de bloque de los sistemas FAS es de 4KB.

 

Cuando trabajamos en modo SAN, el sistema de almacenamiento exporta una LUN, o disco SCSI virtual, a un servidor. Ya sea mediante iSCSI, FC o FCoE, el servidor termina viendo algo que piensa que es un disco y al que acceder mediante comandos SCSI.

 

En los servidores, el tamaño de bloque para acceder a los discos suele ser más pequeño, normalmente es 512 bytes. Y esto nos lleva a una situación incómoda:

 

Problema 1:

Imaginemos que un servidor quiere escribir 512 bytes de datos en una zona de una LUN que está almacenada en un sistema de almacenamiento NetApp, y por tanto, con tamaño de bloque de 4KB.  El servidor mandaría un comando como este (es un ejemplo, nunca he hablado SCSI):

 

scsi_write (25000, 512, “En un lugar de la Mancha, de cuyo nombre no quiero  acordarme, no ha mucho tiempo que vivía un hidalgo de los de lanza en astillero, adarga antigua, rocín flaco y galgo corredor. Una olla de algo más vaca que carnero, salpicón las más noches, duelos y quebrantos los sábados, lentejas los viernes, algún palomino de añadidura los domingos, consumían las tres partes de su hacienda.  El resto della concluían sayo de velarte, calzas de velludo para las fiestas con sus pantuflos de lo mismo, los días de ...”

 

En este ejemplo, 25000 sería el primer bloque de datos a escribir, aunque en la realidad se direccionan los bloques en base a cilindros y sectores, lo cual es más raro, puesto que una LUN no está hecha por un disco circular con cilindros … eso es lo que se llama la geometría virtual de la LUN, que la hace emular un disco rotatorio de los de siempre, en cuanto al direccionamiento de la información que contiene.

 

512 sería la longitud en bytes de la escritura, y el resto los datos que queremos escribir. Esto también nos da una idea de que 512 bytes es bastante información, pero en esta época digital, todo lleva fotos y videos que engordan nuestros archivos y llenan nuestros discos.

 

Para los que sepáis, o queráis saber, un poco más de esto, en realidad el proceso de escritura SCSI es un poco más complicado; aquí hay mucha más información: "SCSI Block Commands - 3 (SBC-3)"


Bien, cuando el sistema de almacenamiento recibe esta orden, tiene algo de trabajo extra. Resulta que en su acceso a los discos físicos, solo trabaja con bloques de 4KB, lo que significa, que para poder modificar 512 bytes, tiene que leer el bloque de 4KB en cuestión, modificar los 512 bytes del contenido, y volver a escribir los 4KB enteros, con parte del contenido original, y parte del contenido modificado.

 

Esto supone que una operación de escritura de un bloque se termina convirtiendo en dos operaciones, una de lectura y otra de escritura, y peor aún, dado que las operaciones no se pueden paralelizar, el tiempo de servicio de la operación de escritura desde el servidor es la suma del tiempo que se tarda en leer el bloque de disco y volver a escribirlo.

 

Para este problema, y si tenemos operaciones desde los servidores que leen o escriben cantidades pequeñas de datos, es más interesante disponer de tamaños de bloque pequeño en el sistema de almacenamiento, y desde luego lo mejor es tener el mismo tamaño de bloque en la aplicación y el sistema de almacenamiento, o utilizar en la aplicación un múltiplo del tamaño de bloque de la cabina; esto no supone mucho “overhead”, puesto que las cabinas pueden agrupar las operaciones que mandan a sus discos.

 

Lo que si penaliza mucho es tener un tamaño menor en los bloques de la aplicación que en la cabina, y esto puede llegar a condicionar la idoneidad o no de un sistema de almacenamiento para determinadas aplicaciones.

 

Bien, para simplificar pensemos en que el tamaño de bloque de la aplicación, o del sistema de ficheros, es igual que el de la cabina, digamos 4KB. ¿Qué pasa si el comienzo de los bloques de datos de la aplicación no coincide con el comienzo de los bloques de la cabina? Pues esto es a lo que llamamos:

 

Problema 2:

 

desalineado.jpg


En esta situación se conoce como desalineación de los datos, y es algo que ocurre con mucha frecuencia y que afecta a todos los sistemas de almacenamiento.

 

Los tamaños de bloques de los sistemas de ficheros suelen ser mayores, por ejemplo 64KB, pero los bloques que se direccionan son de 512 en 512 bytes, por lo que cada uno de los bloques de 64KB puede empezar en cualquiera de los bloques de 512 bytes que se direccionan, y si su comienzo no coincide con los de los bloques físicos de la cabina, todos los bloques del sistema de ficheros se encontrarán desalineados.

 

Las geometrías virtuales de las LUNs se ocupan de informar al sistema operativo cliente de cómo tienen que escribir los datos, y trabajando de forma nativa los servidores construyen la gran mayoría de las veces sus sistemas de ficheros alineando sus bloques con los de la cabina que utilizan. Los mayores problemas nos los encontramos en los sistemas de virtualización de servidores, donde suele haber una capa intermedia, la del hypervisor, que es el que accede a las LUNs y construye el sistema de ficheros, normalmente bien alineado, sobre el que luego crea ficheros planos que son discos virtuales para las máquinas virtualizadas, y en este paso es relativamente sencillo perder la alineación de los bloques de datos de la máquina virtual con el sistema de almacenamiento.

 

En esta situación una operación de escritura sobre uno de los bloques de la máquina virtual supone tener que leer dos bloques de los discos de la cabina, pegar en memoria el trozo de datos cambiado, y luego realizar dos escrituras sobre los discos. Esto supone que una operación de escritura se convierte en 2+2 operaciones en disco, y como avanzábamos antes, con la penalización en tiempo de servicio de tener que esperar a que terminen las lecturas para poder comenzar con las escrituras.

 

El caso de las lecturas es algo más leve, puesto que una lectura se convierte en 2 operaciones de lecturas de disco, pero siguen siendo operaciones gratuitas que merman el rendimiento de nuestra plataforma, y podemos estar hablando de reducir el rendimiento a la mitad ... parece interesante preocuparse por ello.

 

En el siguiente post veremos cómo se detectan datos desalineados y como se puede corregir; por ahora tenéis más información sobre el tema de la alineación en este documento.

 

Saludos

 

PD: El texto de este artículo cabe en 2 bloques de 4KB, el dibujo ocupa otros 8 bloques

Comments

Filter Blog

By date:
By tag: