Diseño de los Cluster Shared Volumes (CSV) en Hyper-V

  • Article

Hola

El diseño del almacenamiento para soluciones de virtualización es un tema ciertamente importante, y muy a menudo recibimos consultas acerca de cómo llevar a cabo el diseño de los “datastores” que albergarán máquinas virtuales, y en particular sobre los Cluster Shared Volumes. Tratamos el tema del funcionamiento y otras consideraciones de los CSVs en este post:

y esta es una buena guía al respecto:

Recapitulando algunos puntos de estos artículos, y añadiendo algunos otros:

Límites

  • Un CSV es un volumen normal de Windows, y la LUN subyacente servida desde el almacenamiento será como cualquier otra LUN que presentamos a un host Windows. Usaremos FC, iSCSI, FCoE, con MultiPath, y DSMs (Device Specific Modules) específicos en función del fabricante y modelo de la cabina.
  • Los límites máximos del tamaño de un CSV son exactamente los mismos que los de un volumen normal de Windows: 256 TB (menos 64KB Sonrisa). Por lo tanto el máximo tamaño de LUN que podemos servir desde el almacenamiento es 256 TB. Como de costumbre en estos casos, el límite está mucho más lejos de lo resulta realmente factible, práctico y razonable, pero siempre hay gente a la que le gusta comparar estas cosas.
  • El número máximo de CSVs por cluster es igual al numero máximo de volúmenes por host. Y no existe tal límite. Sin embargo si que hay un número máximo de LUNs por target y un numero máximo de LUNs por HBA, mas relacionados con los limites de las tecnologías de almacenamiento subyacentes que por el propio sistema operativo. Pero de nuevo, estos límites están más allá de lo que acabaremos usando en realidad.
  • El numero máximo de máquinas virtuales por CSV sería proporcional al numero máximo de ficheros por volumen, que es 4.294.967.295 (menos 1 fichero Sonrisa). Pongamos que cada VM son 10 ficheros (o 100 si queréis). Tampoco parece que haya mucho de qué preocuparse en este sentido.

Rendimiento

¿Cuales son los parámetros que pueden afectar al rendimiento de un CSV?. Pues básicamente los mismos que afectan a cualquier volumen que usemos para almacenar datos, sea DAS, NAS o SAN, pero con la peculiaridad adicional de que cada una de las máquinas virtuales almacenadas en el mismo contribuirá con su propio patrón de IO. Este problema no es en realidad específico de los CSVs, sino de cualquier otro volumen que almacene varias máquinas virtuales. Sin embargo, en el caso de los CSVs, serán varios hosts los que estarán generando carga de trabajo sobre el sistema de almacenamiento subyacente de manera simultánea.

Resumiendo, estas son cosas que afectan al rendimiento de un CSV.

  • Tipo de disco (SSD, FC, SAS, SATA)
  • Tipo de RAID y numero de discos que lo conforman. A mayor número, mejor rendimiento, pero los diferentes tipos de RAID afectan de diferente manera a las operaciones de lectura y/o escritura y sus latencias.
  • Virtualización del almacenamiento. Los conjuntos de discos físicos agrupados en los diferentes tipos de RAID, se suelen “particionar” en LUNs que podemos servir a diferentes hosts. Pueden decirte que tu volumen (CSV o no) esta puesto sobre un conjunto de muchos discos rapidísimos y que todo debería ir estupendamente, pero resulta que sobre ellos residen otras LUNs de otros servidores que pueden estarte restando rendimiento del teórico total.
  • Las controladoras HBAs, NICs, CNAs etc. Las encontraremos en los host y en los dispositivos de almacenamiento. Dan un cierto ancho de banda máximo en ambos extremos, que es conveniente conocer
  • Los “caminos”. En almacenamiento SAN, las comunicación con los dispositivos de almacenamiento se realiza a través del “caminos” de fibra o cobre que están interconectados entre si a través de switches más o menos dedicados o compartidos. Todo aquel que haya intentado ir a un gran centro comercial en la víspera de una fecha señalada sabrá que muchas veces el problema no es otro que el “SAN congestion” que te encuentras antes y después de conseguir el objeto deseado.
  • Los sistemas de almacenamiento. Hoy en día están compuestos por auténticos sistemas operativos diseñados a medida con funcionalidades para gestionar el almacenamiento cada vez más avanzadas, y que ofrecen diferentes posibilidades de escalabilidad y tolerancia a fallos.
  • Las caches. Las tenemos en todas partes. En los sistemas operativos, en las controladoras del servidor, en los dispositivos de la cabina, en los propios discos… . Es muy importante ser conscientes de que caches están actuando entre la petición del dato por parte de una aplicación y el medio físico donde está almacenado, y las posibilidades de optimización que tenemos en nuestra mano.
  • El sistema de archivos:
  • El problema del alineamiento de particiones es especialmente importante en entornos de virtualización.
  • Otro parámetro que tiene relevancia en el rendimiento de un volumen NTFS es el tamaño de bloque:

https://msdn.microsoft.com/en-us/library/cc767961.aspx

Choosing a cluster size. Choose a volume's cluster size based on the average type and size of file that the volume will store. Ideally, the volume cluster size is evenly divisible by the average file size (rounded to the nearest kilobyte). This ideal cluster size minimizes disk I/O transaction overhead and wasted disk space. For example, suppose you're creating a new NTFS volume that will store several files of about 6KB each in size. Format the volume with a 2KB cluster size, because the average file will fit evenly into three clusters. What if the average file size is about 16KB? In that case, a 4KB cluster size will provide the best performance, because it's evenly divisible into 16KB and requires only half the cluster allocations that the same file would require using 2KB clusters. Why not take this process one step further and use an 8KB or 16KB cluster size? These values are valid alternatives and might yield additional performance benefits; however, using cluster sizes greater than 4KB has several potentially negative side effects. For example, when you use cluster sizes larger than 4KB, disk-defragmentation utilities can't defragment the volume, you can't use NTFS file compression on the volume, and the amount of wasted disk space increases because user data files stored on the volume don't end evenly on cluster boundaries.

Como regla general, debemos de pensar que la controladora del host va a leer o escribir los datos en el sistema de almacenamiento en bloques iguales al tamaño del Stripe Size subyacente, independientemente de lo que ocupe el dato. Por otro lado, en entornos virtualizados, con los tipos de datos que manejamos hoy en día, y en virtud del párrafo anterior, parece que tiene sentido formatear nuestros datastores y discos virtuales de datos con tamaños de bloque grandes. Por defecto, un volumen normal del orden de decenas de GB se formatea a 4KB en lugar de a 64K, que es el máximo en NTFS a fecha de hoy.

¿Cuantos CSVs por cluster, y cuantas VMs por CSV?

Pues a la vista de todo lo anterior solo cabe una respuesta. Depende. Personalmente, creo que la respuesta acertada pasa por la estandarización, que nos obliga por necesidad a conocer y manejar los parámetros mencionados anteriormente. Esto, obviamente, deja la libertad de diseñar algo “ad-hoc” si la una solución específica lo requiere.

  • En los sistemas de almacenamiento:
  • Diferentes tipos de disco (por precio, rendimiento…).
  • Diferentes tamaños y parámetros de vRAIDs, agregados, etc. (por rendimiento, aprovechamiento del espacio…).
  • CSVs
  • Diferentes tamaños (p.e. 100 Gb, 250 Gb, 500 GB, 1TB). Tengamos en cuenta que un CSV grande dará el mismo rendimiento que 10 pequeños que sumaran la misma capacidad, si todos van a residir en el mismo contenedor del sistema de almacenamiento. Sin embargo, el tamaño del CSV (o de cualquier datastore) es la “cesta” que se nos puede caer en un momento dado, y de la que tendremos que planificar por ejemplo copias de seguridad y mecanismos de restauración. Recordemos que por la manera que tienen de funcionar los CSVs, incluso aunque hagamos copia de seguridad de una VM, estaremos afectando a las demás, ya que entrará en modo redirigido durante el tiempo que dure el snapshot VSS.
  • Diferentes tamaños de bloque NTFS. Lo normal en un CSV es que se almacenen máquinas virtuales que produzcan patrones de IO muy dispares. Como regla general es conveniente irse a tamaños de bloque grandes. Pero si vamos a usar cargas de trabajo con patrones de IO muy homogéneos, podría tener sentido afinar este valor.
  • VHDs
  • Diferentes tamaños y tipos de formato, en función de su uso, y, por supuesto, nada de VHDs de crecimiento dinámico.
  • Discos para sistema operativo: 10 GB, 20 Gb, 40 GB…
  • Discos para datos con diferentes tamaños acorde a los datos (los discos Pass-Through no aplican a los CSVs).

Una vez establecido este catálogo, iremos presentando CSVs al cluster y llenándolos de máquinas virtuales bajo demanda. De esta forma lograremos trabajar con el almacenamiento de la manera más predecible y ordenada posible. Por ejemplo:

    • Crearemos los VHDs de arranque del sistema operativo de las máquinas virtuales en CSVs de tamaño medio, creados en arrays de discos con un rendimiento bajo, medio o alto en función de la criticidad de la VM.
    • Crearemos los VHDs con los datos de las aplicaciones sobre CSVs que residan en arrays de discos optimizados para esa carga de trabajo (%lectura vs. %escritura, %random vs. %secuencial, etc.), o sobre CSVs genéricos, si el rendimiento no es lo más importante.
    • Tenderemos a agrupar en el mismo CSV las VMs que tengan similares políticas de copia de seguridad.

Por supuesto, hay otra manera de abordar el problema. Te dan una LUN de un cierto tamaño, conviertes el volumen en CSV y lo vas llenando hasta que reviente. Si usas discos de crecimiento dinámico, ten por seguro que te enterarás de cuando sucede eso, porque todas las VMs que tengan discos en ese CSV se habrán quedado en estado pausado. No hay problema, porque los CSVs se pueden agrandar en caliente, y siempre puedes hacerlo crecer (ampliando la LUN en la cabina, te vas al nodo que es el owner del CSV y extiendes el volumen con el Disk manager o Diskpart). Pero llegará el momento en que dará miedo ver una cesta tan rebosante, pediremos crear una nueva LUN, y vuelta a empezar. Y luego resultará que “todo va lento”, entre otras calamidades.

Saludos

David Cervigón