Tamaño de VMware VMFS5 y LUN: ¿múltiples almacenes de datos más pequeños o 1 gran almacén de datos?

Con VMFS5 ya no tiene el límite de 2 TB para un volumen VMFS, estoy considerando qué escenario sería más beneficioso en general:

• Menos LUN de mayor tamaño, o
• Más LUN de menor tamaño.

En mi caso, tengo una nueva matriz de almacenamiento de 24 discos con discos de 600 GB. Usaré RAID10, aproximadamente 7.2TB, y trataré de decidir si voy con 1 gran almacén de datos de 7TB, o múltiples tiendas de 1TB cada una.

¿Cuáles son los pros y los contras de cada enfoque?

Actualización : Por supuesto, olvidé incluir repuestos dinámicos en mi cálculo, por lo que será un poco menos de 7.2TB, pero la idea general es la misma. :-)

Actualización 2 : hay 60 máquinas virtuales y 3 hosts. Ninguna de nuestras máquinas virtuales es particularmente intensiva en E / S. La mayoría de ellos son servidores web / de aplicaciones, y también cosas como monitoreo (munin / nagios), 2 DC de Windows con carga mínima, y ​​así sucesivamente. Los servidores de bases de datos rara vez se virtualizan a menos que tengan requisitos de E / S MUY bajos. En este momento, creo que el único servidor de base de datos virtual que tenemos es una caja MSSQL y la base de datos en esa caja es <1GB.

Actualización 3 : algo más de información sobre la matriz y la conectividad FC. La matriz es un IBM DS3524, 2 controladores con 2 GB de caché cada uno. 4 puertos de 8 Gbit FC por controlador. Cada host ESXi tiene 2x 4 Gbit FC HBA.

No especificó cuántas máquinas virtuales tiene o qué van a hacer. Incluso sin esa información, evitaría que uno haga un gran LUN por razones de tamaño de bloque / rendimiento, contención y flexibilidad.

Asumiré que vas a virtualizar servidores, no escritorios, ¿de acuerdo? A continuación, voy a suponer que va a utilizar varios servidores ESX / ESXi para acceder a su almacenamiento y que vCenter Server los administre.

Al decidir sobre el tamaño de LUN y la cantidad de VMFS, está equilibrando varios factores: rendimiento, flexibilidad de configuración y utilización de recursos, mientras está sujeto a la configuración máxima admitida de su infraestructura.

Puede obtener el mejor rendimiento con la asignación de 1 VM a 1 LUN / VMFS. No hay competencia entre máquinas en el mismo VMFS, no hay contención de bloqueo, cada carga está separada y todo es bueno. El problema es que va a administrar una cantidad impía de LUN, puede alcanzar los límites máximos admitidos, enfrentar dolores de cabeza con el cambio de tamaño y la migración de VMFS, tener recursos subutilizados (ese espacio libre de puntos porcentuales en VMFS se suma) y, en general, crea algo que No es agradable de administrar.

El otro extremo es un gran VMFS designado para alojar todo. Obtendrá la mejor utilización de los recursos de esa manera, no habrá problemas para decidir qué implementar y dónde, y los problemas con VMFS X son un punto caliente, mientras VMFS Y está inactivo. El costo será el rendimiento agregado. ¿Por qué? Por bloqueo. Cuando un ESX está escribiendo en un VMFS determinado, otros están bloqueados por el tiempo que lleva completar IO y deben volver a intentarlo. Esto cuesta rendimiento. Fuera de los entornos de juegos / prueba y desarrollo, es un enfoque incorrecto para la configuración de almacenamiento.

La práctica aceptada es crear almacenes de datos lo suficientemente grandes como para alojar varias máquinas virtuales y dividir el espacio de almacenamiento disponible en fragmentos de tamaño adecuado. El número de máquinas virtuales depende de las máquinas virtuales. Es posible que desee una o dos bases de datos de producción críticas en un VMFS, pero permita tres o cuatro docenas de máquinas de prueba y desarrollo en el mismo almacén de datos. El número de máquinas virtuales por almacén de datos también depende de su hardware (tamaño de disco, rpm, caché de controladores, etc.) y patrones de acceso (para cualquier nivel de rendimiento dado, puede alojar muchos más servidores web en el mismo VMFS que los servidores de correo).

Los almacenes de datos más pequeños también tienen una ventaja más: le impiden físicamente acumular demasiadas máquinas virtuales por almacén de datos. Ninguna cantidad de presión de administración se ajustará a un terabyte adicional de discos virtuales en un almacenamiento de medio terabyte (al menos hasta que escuchen sobre aprovisionamiento delgado y deduplicación).

Una cosa más: al crear esos almacenes de datos, se estandarizan en un solo tamaño de bloque. Simplifica muchas cosas más adelante, cuando quieres hacer algo en los almacenes de datos y ver feos errores "no compatibles".

Actualización : DS3k tendrá controladores activos / pasivos (es decir, cualquier LUN dado puede ser atendido por el controlador A o B, el acceso al LUN a través del controlador no propietario incurre en una penalización de rendimiento), por lo que valdrá la pena tener un número par de LUN , distribuido uniformemente entre los controladores.

Me imagino comenzando con 15 VM / LUN con espacio para crecer hasta 20 más o menos.

La respuesta breve a su pregunta es: todo depende de cuáles sean sus patrones de E / S, y esto será exclusivo de su entorno.

Le sugiero que eche un vistazo aquí http://www.yellow-bricks.com/2011/07/29/vmfs-5-lun-sizing/ ya que esto puede ayudarlo a considerar sus IOPS anticipados y cuántos LUNS podrían ser adecuados. Dicho esto, si tuviera que errar por precaución, algunas personas recomendarían tener muchos LUNS (si se aprueba mi corrección a una respuesta anterior, vea mis comentarios sobre las colas de LUN IO en el lado de la matriz). Tiendo a estar de acuerdo, pero iría más allá para luego extenderlos juntos en un solo / pocos volúmenes VMFS (no le creas al FUD sobre extensiones, y otros límites VMFS http://virtualgeek.typepad.com/virtual_geek/2009/03 /vmfs-best-practices-and-counter-fud.html) Esto tendrá el beneficio de administrar un único / pocos almacenes de datos dentro de vSphere y, dado que vSphere equilibra automáticamente las máquinas virtuales sobre las extensiones disponibles, comenzando con el primer bloque de cada extensión, el beneficio de rendimiento distribuye su IO en múltiples LUN.

Algo más a considerar ... Usted dice que ninguna de las máquinas virtuales es particularmente intensiva en IO. Dado esto, puede considerar una combinación de RAID5 y RAID10, para obtener lo mejor de ambos mundos (espacio y velocidad).

Además, si tiene sus máquinas virtuales configuradas con múltiples VMDK, con el SO y los patrones de E / S de la aplicación distribuidos en esos discos virtuales (es decir, SO, web, base de datos, registros, etc., cada uno en un VMDK separado), puede ubicar cada VMDK en un almacén de datos diferente para que coincida con las capacidades de IO de ese LUN físico (por ejemplo, SO en RAID5, Registros en RAID10). Se trata de mantener juntos patrones de E / S similares para aprovechar el comportamiento mecánico de los discos subyacentes para que, por ejemplo, las escrituras de registros en una VM no afecten las velocidades de lectura web en otra VM.

Para su información ... puede virtualizar con éxito los servidores de base de datos, solo necesita analizar los patrones de IO y las tasas de IOPS y dirigir ese IO a un LUN adecuado; todo el tiempo consciente de los patrones de IO y IOPS que LUN ya está haciendo. Por ello, muchos administradores de la culpa de los malos resultados virtualiseation DB ... cos que no calcularon con cuidado la IO / IOPS que varios servidores generarían cuando se los pusieron en un LUN compartido (es decir. Quejar los administradores, no es culpa de la virtualización )

Cada volumen (LUN) tiene su propia profundidad de cola, por lo que para evitar la contención de E / S, muchas implementaciones usan LUN más pequeños. Dicho esto, puede hacer que un almacén de datos abarque LUN con bastante facilidad. La desventaja de los almacenes de datos VMWare más grandes (y menos) es, hasta donde yo sé, que puedes encontrar algunos límites en la cantidad de máquinas virtuales que podrían estar en funcionamiento simultáneamente.

Otra consideración es el rendimiento del controlador. No conozco su SAN específicamente, pero la mayoría de las SAN, si no todas, requieren que un LUN sea propiedad de un solo controlador a la vez. Desea tener suficientes LUN en el sistema para poder equilibrar su carga de trabajo entre los controladores.

Por ejemplo, si solo tuviera un LUN, solo estaría usando un controlador activo a la vez. El otro se quedaría inactivo ya que no tendría nada que hacer.

Si tuviera dos LUN, pero uno estuviera mucho más ocupado que el otro, estaría usando ambos controladores pero no de la misma manera. A medida que agrega más LUN, los controladores comparten la carga de trabajo de manera más uniforme.

Consejos específicos para ti:

Sus máquinas virtuales son relativamente iguales en términos de requisitos de rendimiento. Crearía dos LUN, uno por controlador. Comience a colocar máquinas virtuales en el primer LUN y mida su latencia de E / S y la profundidad de la cola a lo largo del tiempo a medida que las VM se instalen. No use el segundo LUN todavía. Continúe llenando el LUN 1. Llegará a un punto en el que comenzará a ver indicadores de rendimiento de que el LUN está lleno, o habrá migrado la mitad de sus máquinas virtuales a ese LUN, y aún así ha mantenido el rendimiento.

Si ve problemas de rendimiento, eliminaría el 30% de las máquinas virtuales del LUN 1 y las movería al LUN 2. Luego comenzaría a llenar el LUN 2 de la misma manera. Vaya a LUN 3 si es necesario ... ¿tiene sentido? La idea es lograr la máxima densidad de VM en un LUN determinado junto con una sobrecarga de aproximadamente el 30% para la sala de fudge.

También haría un par de LUN de "alto rendimiento" para cualquier VM de gran impacto. Una vez más, uno por controlador para compartir la carga de trabajo.

Según sus explicaciones anteriores, debería estar bien con 1 almacén de datos. 60 vm en más de 3 hosts no es tan malo (20: 1). Sin embargo, le recomendaría que actualice los HBA a 8 Gb si es financieramente posible en al menos un host siempre que su conmutador de fibra sea un conmutador de 8 Gb como mínimo.

Dicho esto, haría al menos 2, si no 3, almacenes de datos en la matriz. 1 almacén de datos por host, con todos los servidores accediendo a los demás para vMotion. No sé mucho sobre la matriz de IBM; con EMC, crearía un solo grupo RAID10 con 3 LUN para cada almacén de datos. Con esta configuración, el host con los HBA de 8 Gb sería ideal para sus sistemas de E / S superiores.

Puede hacer 1 almacén de datos / servidor, y hay algunas instancias que lo hago yo mismo, pero solo lo hago con la replicación SAN en servidores especiales. ¡Administrar 87 almacenes de datos diferentes en 9 servidores para vMotion se vuelve confuso cuando lo configura! La mayoría de mis máquinas virtuales están en almacenes de datos compartidos con 5-10 servidores, dependiendo de cuánto espacio necesiten.

Una nota final. Si tiene algún tipo de servidor en un par / clúster de conmutación por error o carga equilibrada, los querrá en diferentes almacenes de datos. No desea que el almacén de datos falle y luego se quede sin servidores. Es cierto que si pierde la matriz, lo ha perdido todo, pero es por eso que respaldamos, ¿verdad?