Sobre el tamaño de las LUN & los Datastores en entornos VMware

Todo administrador de un entorno virtualizado (entendiendo que se entiende con ello, que dispone de almacenamiento consolidado), se plantea la disyuntiva del tamaño de las LUNs y el número de VMs que alojar en cada porción de disco.

Lo mas fácil es ir al extremo y definir una LUN “enorme”, de X terabytes en la que almacenaremos todas las máquinas virtuales.

Este sistema tiene una ventaja, y es que a menor cantidad de LUNs, menor cantidad de trabajo a gestionar tanto en cabina, como a nivel de masking, zoning y por último a nivel de Datastore* el administrador disminuye un área de gestión importante en todo centro de datos.

*Datastore:  De forma simplificada podemos decir que es la nomenclatura utulizada por VMware para designar a cada una de las LUNs visibles, si bien esto tiene ciertos matices que van más allá del objeto de este artículo).

Por contra, con este planteamiento, aparecen diversos problemas, unos menores, otros no tanto que se resuelven o minimizan con un tratamiento del almacenamiento diferente.

Vista de vCenter en el apartado de gestión de Datastores

Según algunos whitepapers de VMware, lo recomendable en general son LUNs de no más de 500 GB, si bien este dato dicho en frío tiene mucho de discutible.

Cuando VMware crea un sistema de archivos sobre cierta LUN, pasamos a denominar a esta como “Datastore” y es a partir de dicho momento en el que podemos hacer uso de la misma.

El sistema de archivos creado se denomina VMFS, y es un tipo de filesystem con capacidad de clustering, acceso múltiple y  concurrente por varias máquinas. Esto permite que en un solo datastore, residan, lean y escriban en un mismo momento varias máquinas virtuales y por tanto convivan de forma “pacífica”.

Lo que hay detrás, es que como consecuencia,  el sistema de archivos tiene que disponer de un sistema de bloqueos muy desarrollado adapado a dicho tipo de acceso y preparado para  un conjunto de máquinas con una fuerte carga de transacciones de disco que incluso puede poner en serios apuros al sistema de disco.

Es por ello que un solo datastore , con un gran número de máquinas virtuales conlleva un mayor número de bloqueos y operaciones concurrentes y por tanto en ciertos “micro-momentos” habrá VMs, a la espera de su tiempo de atención de disco y/o desbloqueo de cierta área del mismo.

Como consecuencia, el rendimiento del sistema de disco con las máquinas virtuales que corren sobre él, se ve decrementado y alguien empieza a pensar que la red SAN no es tan “galáctica” como aquel comercial se empeñaba en aseverar antes de su adquisición.

Otros pensarán que todo es culpa de la capa de virtualización y el modelo tradicional de “una máquina por servidor físico” es totalmente irremplazable.

Es por ello que también hay quien apunta una regla, de forma general, que dicta que en un datastore no se deben acumular más de 10 VMs (y con ello limitar hasta cierto punto el número de colisiones de disco por  área de almacenamiento).

¿Es entonces el tamaño del datastore o el número de VMs, lo que limita el rendimiento del sistema?, como el lector podrá suponer, ni todo es blanco…

Una mezcla de ambos componentes es lo que determina un correcto acceso a disco (prescindiendo en este pequeño examen, el tipo de almacenamiento, rendimientos, tipos de RAID y tecnología de disco, canal de acceso, caches de controladoras, y muchas otras variables a considerar en un proyecto real).

Podría pensarse que si utilizamos LUNs de menos de 500 GB y menos de 10 VMs por LUN, nos acercamos a un modelo simple de acción, pero creo que estamos de acuerdo si preciso que no aporta la misma carga, el servidor Oracle del ERP corporativo que un servidor de impresión, y por tanto será preciso medir las necesidades de acceso a disco de cada servidor y/o aplicación en cada caso para decidir el número de LUNS, las VMs que pueden ser vecinas de piso o aquellas que deben ser realojadas en lugares diferentes y mas “exclusivos” de nuestra red de almacenamiento.

Digamos que la norma a seguir pasa por no rebasar, siempre que sea factible, un 80% del rendimiento del sistema de disco por LUN, y asociar en cada una un conjunto de VMs que en su acceso total medio  no sobrepase un el límite de operaciones por segundo o requerimientos de MB/Seg por encima de la regla de negocio definida.

La contrapartida es cierta y es en la que estás pensando: Hay que crear, administrar y gestionar mas LUNs en el sistema, pero todo sea porque la aplicación de gestión de incidencias no aumente su carga con las  de tipo “esto me va lento…”

¿Que porcentaje a reservar para instantáneas en cabina?, ¿disminución de rendimiento asociada a asignación ligera de disco por VM? y ¿como repercute todo lo anterior en el sistema de backup?

Será obejeto de otro artículo , porque este acaba de terminar…;-)