Elementos para el dimensionamiento del almacenamiento en una solución de Hiperconvergencia

Las soluciones de hiperconvergencia están siendo adoptadas de manera masiva y no están restringidas a unos casos de uso. La primera pregunta que viene por parte de los clientes es: tengo un espacio efectivo de digamos 60 Terabytes sobre el que almaceno mis máquinas virtuales ¿Cuánto almacenamiento necesito ahora con vSAN?

Más allá de hacer un diseño propio, la idea de esta guía es entender las razones de diseño de la solución. Esto también puede ser útil para operar la solución una vez ha sido adquirida. Si usted quiere diseños ya probados están cientos de configuraciones con fabricantes como HPE, DellEMC, Lenovo, Supermicro y muchos otros en [10] o en la solución de VXRail Sizer Express https://mainstayadvisor.com/go/emc/vxrail/ . Por supuesto el sitio más completo es http://storagehub.vmware.com

Elementos para el cálculo

Lo primero es definir exactamente que es espacio efectivo. Espacio efectivo hace referencia al almacenamiento que sea suficiente para albergar las máquinas virtuales con las características de protección que la entidad necesita. Ahora, tenemos que entender cómo funciona la hiperconvergencia. La solución de vSAN tienen como función principal, pero no la única, en presentar almacenamiento a vSphere. En términos prácticos la hiperconvergencia de VMware (vSAN) expone automáticamente un Datastore al vCenter utilizando servidores de rack de casi cualquier fabricante de Hardware de Datacenter [2][3].

Slack: Es evidente que la solución debe tener la capacidad de tolerar fallas de hardware como la pérdida de discos, un conjunto de discos o un host completo sin que las máquinas virtuales se vean afectadas. Esto se traduce en espacio disponible para que en el caso de una de esas fallas pueda hacer rebalanceo de los datos (componentes). Este espacio disponible se denomina slack y se recomienda que sea de aproximadamente un 25% a un 30% [4]. El espacio de slack considera otras cosas [5], pero el rebalanceo y la capacidad de absorber las fallas de hardware se encuentran entre las principales funciones.

Checksum: vSAN incorpora implanta un mecanismo de chequeo para garantizar la consistencia de los datos. Esto se denomina Checksum y se estima en un 5%.

Formateo de Discos: El formateo de Discos tiene una carga del 1% adicional

Compresión y deduplicación. vSAN incorpora mecanismos eficientes de compresión y deduplicación. ¿Se debe incluir dentro del diseño de la solución? En general si uno no tiene un conocimiento claro de las VMS que van a correr sobre la solución no es fácil determinar que tanto va a disminuir el consumo de disco. Generalmente es prudente no dimensionar contando con una compresión y deduplicación determinada.

Protección de máquinas virtuales: vSAN permite asignar una política de almacenamiento y protección a cada una de las máquinas virtuales.

Dependiendo del número de hosts físicos se puede asignar una u otra política. En el caso de los almacenamientos con discos rotacionales la única opción es RAID-1. En cuyo caso requeriría el doble de espacio de la solución. Para soluciones de 4 o más nodos es posible utilizar otros mecanismos de protección como RAID-5. El algoritmo de protección (Erasure Coding) exige que se necesite apenas un 33% de espacio [6] adicional.

Memoria Virtual (SWAP). Ahora en la versión 6.7 de vSAN el abastecimiento de SWAP se hace, por defecto, de manera delgada (thin) [14]. En versiones anteriores se hacía de manera gruesa (thick) situación que hacía que en muchos casos se ocupara literalmente cantidades significativas de espacio. En [15] y [16] se explica en detalle como hacer los cambios en versiones anteriores de vSAN.

Consideraciones en el número de nodos

El mecanismo de protección de máquinas virtuales determina la cantidad de discos para una solución de hiperconvergencia. Hagamos primero el ejercicio de dimensionar la solución en tres nodos: 60 Terabytes * 1.25 de Slack*1.05 de Checksum*1.01 de Formateo de discos* 2 en RAID-1 = 60*2*1,25*1,05*1,01=159,075 Terabytes de espacio raw para satisfacer el requerimiento de espacio efectivo

Ahora, si hacemos el mismo ejercicio pensando en 4 hosts tenemos:60 Terabytes * 1.25 de Slack*1.05 de Checksum*1.01 de Formateo de discos* 1.33 en RAID-5 = 60*1,33*1,25*1,05*1,01=105,78 Terabytes de espacio raw para satisfacer el requerimiento de espacio efectivo [8]

En términos prácticos, puede resultar más conveniente tener una solución de 4 hosts que una de 3 hosts pues las posibilidades para aplicar las políticas de protección son más efectivas en términos de consumo de disco en arquitecturas de 4 o más nodos.

Discos de capacidad para la solución

Ya que tenemos el espacio efectivo (105,78 Terabytes), es necesario que los despleguemos en los 4 servidores que estábamos planeando anteriormente. Para esto es necesario escoger un tamaño de disco que sirva los requerimientos actuales pero que también pueda servir los requerimientos futuros. Es siempre recomendable escoger un tamaño pensando no solo en el hoy sino los posibles crecimientos que podrá tener la solución. En la actualidad los fabricantes de Hardware tienen soluciones de discos de capacidad de tamaños que van de los 200 Gigabytes a los 7.68 Terabytes o más.

Los discos de 3.84 Terabytes tienen en la actualidad un valor bueno por terabyte. En el ejercicio los 105,78 Terabytes divididos entre discos de 3,84 Terabytes nos piden 28 discos. Estos 28 discos divididos entre 4 nodos nos dan 7 discos por nodo. Un diseño posible consistiría en utilizar discos de por ejemplo 1.92 Terabytes que podrían dar mayor rendimiento, y aunque ocupan más bahías permitirían reducir el impacto de un daño. De otra parte este beneficio se paga utilizando más discos de cache.

Tanto para los discos de caché como de capacidad es crítico revisar el endurance (resistencia) de los discos [3] y [12]. Es así mismo crítico asegurarse que el performance de los discos se ajuste a los requerimientos de las guías de dimensionamiento de vSAN [3] y [12].

IOPS – ¿Cuánto es lo que usted verdaderamente necesita?

En algún momento del dimensionamiento va a surgir la pregunta ¿Esto si va a sostener nuestra carga de máquinas virtuales?. Dentro de VMware utilizamos una herramienta de nombre LiveOptics (https://www.liveoptics.com/ ) que permite resolver esta inquietud de manera rápida. La herramienta se puede utilizar de manera libre y genera reportes que desmienten cualquier elemento de requerimientos de millones de IOPS. LiveOptics entrega tres elementos de información relevantes para el diseño de la solución: el número de IOPS al 95% (76 en la imagen), el promedio de escritura diaria para estimar la durabilidad de los discos de caché de vSAN (81,39 Gigabytes) y la proporción de escritura contra lectura (55% escritura y 45% lectura en la imagen mostrada).

Diskgroups: Agrupamiento dentro de la vSAN

vSAN permite crear 7 discos de capacidad por diskgroup y 5 diskgroups por nodo. Cada grupo de discos debe contar con un disco de caché. La información de IOPS que da LiveOptics nos permite pronosticar la durabilidad de dichos discos de caché. Existe en el mismo sitio de LiveOptics un artículo muy didáctico de la durabilidad (endurance) de los discos de estado sólido [11]

La primera aproximación es acumular todos los grupos de discos en el menor número de diskgroups, en el ejemplo que estábamos considerando, los 7 discos caben fácilmente en un solo diskgroup. El concentrar el almacenamiento en un solo grupo de discos puede tener el riesgo que en el caso de falla del disco de cache es necesario rebalancear 26.88 Terabytes. El arquitecto de infraestructura prudente elegirá una configuración con más Diskgroups.

De manera general la regla de la mano derecha en el tamaño de los discos de caché es de un 10% bajo un FTT=1. En el caso de soluciones basadas en estado sólido es diferente. Una guía del tamaño de los discos está ampliamente discutida en [13] y puede ir desde los 400 Gigabytes hasta los 1.6 Terabytes.

Existe una segunda consideración para el tamaño de los discos de caché y es el crecimiento futuro de la solución. ¿Cómo desea el cliente crecer? ,¿Desea solo crecer en discos de capacidad?. Esto es importante saberlo pues el crecimiento de la solución tiene que ser armónica en tamaños y tipos de discos hacia el futuro. En el análisis que estamos haciendo, y utilizando la configuración de discos de 1.92 Terabytes cada nodo luciría de la siguiente manera:

El crecimiento exigiría un disco de caché (color rosado) y un conjunto de discos a través de los nodos para mantener el balanceo de la solución que siempre es deseable.

VSANSizer

Aunque este ejercicio consistió en realizar cálculos manuales siempre es útil acceder al vSAN Sizer: https://vsansizer.vmware.com/ que continuamente va incorporando nuevas características y escenarios. En particular para el ejercicio que se describió en este artículo la recomendación por nodo es muy cercana a la que se concluyó en párrafos anteriores. vSAN Sizer es como una segunda opinión médica, siempre es bienvenida y permite confirmar los cálculos manuales o en muchos casos considerar opciones alternas.

Conclusión

Una de las ventajas de VMware vSAN es su flexibilidad y claridad de diseño. El entender la manera como se diseña permite tener configuraciones va a comportarse de manera predecible y que se podrán ampliar hacia el futuro.