Elección de una tecnología SAN para cientos de servidores web VM

El problema

Tenemos un problema con el rendimiento en una plataforma existente, por lo que me estoy volviendo a la mente de la colmena para obtener una segunda opinión al respecto. El problema de rendimiento hasta ahora se relaciona con IOPS más que con el rendimiento.

El escenario

Un centro blade de 16 hosts, cada uno con 64 GB de RAM. (Es una Dell M1000e con M610s, pero eso probablemente no sea relevante) 500 máquinas virtuales, todos los servidores web (o tecnologías web asociadas como MySQL, equilibradores de carga, etc.), alrededor del 90% son Linux y el resto Windows. Hypervisor es VMWare vSphere. Necesitamos proporcionar host HA, por lo que el almacenamiento local está fuera. Como tal, los hosts solo tienen una tarjeta SD para arrancar.

Un poco de pensamiento de fondo

En este momento tenemos hasta 6 hosts (el centro de la cuchilla estará a plena capacidad en un año en el crecimiento actual) y estamos ejecutando iSCSI a un Dell MD3220i w / MD1220 para expansión.

Posibles opciones que hemos considerado, y pensamientos inmediatos junto con ellas:

• Difundir las máquinas virtuales en almacenes de datos NFS y ejecutar almacenamiento NFS que cumpla con los requisitos de rendimiento para un número determinado de máquinas virtuales. NFS parece más barato de escalar, y se abstrae un poco más que el almacenamiento a nivel de bloque para que podamos moverlo según sea necesario.
• Agregar más controladores / objetivos MD3220i. Sin embargo, nos preocupa que esto pueda tener un efecto negativo de alguna manera en cómo VMWare maneja tener muchos objetivos.
• Intercambiando todos los discos de Nearline SAS a SSD. Esto debería resolver por completo el problema de IOPS, pero tiene el obvio efecto secundario de recortar nuestra capacidad de almacenamiento. Además, sigue siendo muy caro.
• vSphere 5 tiene un dispositivo de almacenamiento. No hemos investigado tanto, pero ¿debe funcionar bien?

La pregunta

¿Qué tipo de almacenamiento ejecutarías debajo de todo eso? No necesitaría escalar a otro centro blade, solo necesitaría proporcionar un rendimiento relativamente bueno para todas esas máquinas virtuales.

No estoy buscando respuestas "Compre SAN x porque es la mejor". Estoy buscando ideas sobre las diversas tecnologías SAN (iSCSI, FC, FCoE, InfiniBand, NFS, etc.), los diferentes tipos de almacenamiento (SATA, SAS, SSD) y las metodologías para manejar el almacenamiento de cientos de máquinas virtuales (consolidación, separación) , Sharding, etc.)

Absolutamente cualquier pensamiento, enlaces, guías, punteros, etc. son bienvenidos en esto. También me encantaría escuchar ideas sobre las opciones anteriores que ya habíamos considerado.

Muchas gracias de antemano por cualquier aportación!

Actualización 5 de marzo '12

Algunas respuestas fantásticas hasta ahora, ¡muchas gracias a todos!

Siguiendo las respuestas a esta pregunta hasta ahora, empiezo a pensar que la siguiente ruta es la siguiente:

• Nivele el almacenamiento disponible en el clúster VMWare y coloque los discos VM en el almacenamiento adecuado para sus cargas de trabajo.
• Potencialmente haga uso de una SAN que sea capaz de gestionar la colocación de datos en un almacenamiento adecuado de forma automática.
• Infiniband parece ser el más rentable para obtener el ancho de banda requerido con los hosts a plena capacidad.

Definitivamente parece que valdría la pena hacer uso de los servicios de preventa de un importante proveedor de SAN para obtener su opinión sobre el escenario.

Voy a seguir considerando este problema por un tiempo. Mientras tanto, más consejos recibidos con gratitud!

La clave para una buena plataforma de almacenamiento VMWare es comprender qué tipo de carga genera VMWare.

• Primero, dado que aloja muchos servidores, la carga de trabajo suele ser aleatoria. Hay muchas transmisiones de E / S que se ejecutan al mismo tiempo, y no muchas de ellas pueden almacenarse previamente en caché.
• Segundo, es variable. Durante las operaciones normales, puede ver lecturas aleatorias del 70%, sin embargo, en el instante en que decida mover una VM a un nuevo almacén de datos o algo así, verá una escritura secuencial masiva de 60 GB. Si no tiene cuidado con la arquitectura, esto puede afectar la capacidad de su almacenamiento para manejar las E / S normales.
• En tercer lugar, una pequeña parte de su entorno generalmente generará una gran parte de la carga de trabajo de almacenamiento.

La mejor manera de abordar el almacenamiento de edificios para una plataforma VMWare es comenzar con los fundamentos.

• Necesita la capacidad de dar servicio a una gran carga de trabajo de lectura aleatoria, lo que significa unidades más pequeñas y rápidas, así como posiblemente SSD. La mayoría de los sistemas de almacenamiento modernos le permiten mover datos automáticamente según cómo se acceda. Si va a usar SSD, debe asegurarse de que así es como lo usa. Debería estar allí como una forma de reducir gradualmente los puntos calientes. Ya sea que use SSD o no, es beneficioso poder realizar todo el trabajo en todas las unidades, por lo que algo con un tipo de agrupación de almacenamiento sería beneficioso.
• Necesita la capacidad de prestar servicio a las escrituras grandes intermitentes, que no se preocupan tanto por la velocidad del eje de las unidades subyacentes, sino por la eficiencia de la pila del controlador y el tamaño de la memoria caché. Si ha duplicado el almacenamiento en caché (que no es opcional a menos que esté dispuesto a volver a las copias de seguridad cada vez que tenga una falla en el controlador), el ancho de banda entre las dos memorias caché utilizadas para duplicar será su cuello de botella para grandes escrituras secuenciales, por lo general. Asegúrese de que todo lo que obtenga tenga un controlador de alta velocidad (o clúster) interconectado para el almacenamiento en caché de escritura. Haga su mejor esfuerzo para obtener una red front-end de alta velocidad con tantos puertos como sea posible sin dejar de ser realista en el precio. La clave para un buen rendimiento de front-end es poner su carga de almacenamiento en tantos recursos de front-end como sea posible.
• Puede reducir seriamente los costos al tener un nivel para almacenamiento de baja prioridad, así como un aprovisionamiento ligero. Si su sistema no está migrando automáticamente bloques individuales a unidades grandes / lentas baratas (como SAS o SATA nearline con 7200 RPM y tamaños de 2TB +), intente hacerlo manualmente. Las unidades lentas grandes son objetivos excelentes para archivos, copias de seguridad, algunos sistemas de archivos e incluso servidores con poco uso.
• Insista en que el almacenamiento está integrado por VAAI para que VMWare pueda desasignar partes no utilizadas de las máquinas virtuales, así como los almacenes de datos.

Mis grandes implementaciones de VMWare son NFS e iSCSI de más de 10 GbE. Eso significa HBA de 10 GbE de doble puerto en los servidores, así como el cabezal de almacenamiento. Soy fanático del almacenamiento basado en ZFS para esto. En mi caso, está envuelto en comerciales NexentaStor , pero algunos optan por rodar el suyo.

Las características clave del almacenamiento basado en ZFS en este contexto serían la funcionalidad de almacenamiento en caché ARC / L2ARC, que le permite almacenar en niveles. Los datos más activos encontrarían su camino en el almacenamiento de RAM y SSD como un segundo nivel. También sería beneficioso ejecutar su grupo de almacenamiento principal en unidades SAS de 10k o 15k.

Este es otro caso de creación de perfiles y comprensión de su carga de trabajo. Trabaje con alguien que pueda analizar sus patrones de almacenamiento y ayudarlo a planificar. En el lado de ZFS / NexentaStor, me gusta PogoStorage . Sin ese tipo de información, el método de transporte (FC, FCoE, iSCSI, NFS) puede no importar. ¿Tiene algún monitoreo de su infraestructura existente? ¿Cómo se ve la actividad de E / S ahora?

La pregunta clave es: "¿dónde está el cuello de botella?" Usted menciona IOPS, pero ¿eso significa que ha identificado positivamente los discos en sí mismos como el cuello de botella, o simplemente que los puertos SAN no están funcionando a su capacidad o que las máquinas virtuales están en mucho más tiempo de lo que desea?

Si definitivamente ha identificado que los discos son el factor limitante, entonces cambiar a NFS o infiniband o lo que no vaya a hacer sentadillas para su rendimiento: necesita SSD (o al menos almacenamiento en niveles con SSD en la mezcla) o un conjunto más de husillos (una solución que se ha vuelto mucho más cara recientemente desde que la producción mundial de motores paso a paso fue arrastrada al océano).

Sin embargo, si no está 100% seguro de dónde está realmente el cuello de botella, debe encontrarlo primero: intercambiar partes de su infraestructura de almacenamiento más o menos al azar según las conjeturas de otras personas aquí no será muy efectivo (especialmente dado lo costoso que será implementar cualquier cambio).

Si desea iscsi o nfs, como mínimo necesitará unos pocos puertos de 10 / 40gb o infiniband, que es la opción más barata con diferencia, pero las soluciones de almacenamiento nativas para infiniband parecen ser limitadas. El problema será el módulo para el bladecenter, cuáles son sus opciones, generalmente 8gb fc o 10 \ 1gbe y quizás infiniband. Tenga en cuenta que infiniband se puede usar con nfs y nada se le cierra en términos de rendimiento \ precio. si el centro de la cuchilla admite qdr infiniband, lo haría con un host de Linux de algún tipo con un qdr infiniband tca a través de nfs. Aquí hay un buen enlace que describe esto http://www.zfsbuild.com/2010/04/15/why-we-chose-infiniband-instead-of-10gige

pero si el bladecenter puede soportar qdr infiniband y puede permitirse el lujo de infiniband nativo, entonces esa es la solución que debe elegir.

Actualmente, puede obtener conmutadores de 40 gbe mucho más baratos (eso es un pensamiento extraño) que los conmutadores de 10 gbe, pero dudo que su centro de cuchillas lo admita.

El almacenamiento local está fuera? Estoy bastante contento con el rendimiento de escritura en mis RAID 5 locales, reflejado con DRBD8 para el socio de clúster de mi máquina XEN ... (pero esto "no es compatible", por supuesto).

Aparte de eso, estoy bastante seguro de que mySQL es su problema de rendimiento (nunca vi un peor DB). Intente sintonizarlo y / o intente poner toda la base de datos en la memoria caché del sistema de archivos (para acceso de lectura) ...