¿Un gran RAID 10 frente a varias matrices más pequeñas?

Mi pregunta es: ¿cuándo es apropiado crear simplemente una matriz grande con un rendimiento rápido de lectura y escritura, como RAID 10, en lugar de crear matrices más pequeñas para aplicaciones específicas?

Me parece que si mis requisitos generales de E / S no son terriblemente pesados, una sola matriz con un excelente rendimiento de lectura y escritura podría proporcionar un mejor rendimiento general para todas las aplicaciones, excepto en aquellos (quizás raros) momentos en que las aplicaciones con diferentes patrones de acceso alcanzaron su punto máximo al mismo tiempo (copiando grandes cantidades de archivos grandes mientras se cierra una base de datos).

Si le dedico un par de ejes a una tarea en particular, como los registros de transacciones, y ni siquiera están sudando con la carga de trabajo ... ¿por qué no simplemente poner esa carga de trabajo en un RAID 10 más grande? Esos husos podrían contribuir a otras cargas de trabajo en lugar de quedarse sentados rascándose el 60% del tiempo.

PD: en mi caso particular, el costo general de RAID 10 no es un factor, porque estoy buscando crear múltiples matrices RAID 1 y una RAID 5. más pequeña. Ir a RAID 10 por la cantidad de espacio que necesito sería comparable.

Saber cómo configurar su almacenamiento se trata de medir y presupuestar el IOPS y el ancho de banda. (Estoy siendo simplista aquí porque el tamaño de la mezcla porcentual de lectura / escritura, E / S promedio, tamaño de banda RAID y porcentajes de aciertos de caché son muy importantes. Si puede obtener esos números, puede hacer que sus cálculos sean aún más precisos).

Hay un pequeño muy agradable IO calculadora aquí que con frecuencia utilizo la hora de planificar el almacenamiento. El directorio de almacenamiento de wmarow también es bueno para obtener algunos números de rendimiento de disco bastante contemporáneos.

Si le dedico un par de ejes a una tarea en particular, como los registros de transacciones, y ni siquiera están sudando con la carga de trabajo ... ¿por qué no simplemente poner esa carga de trabajo en un RAID 10 más grande?

Recuerde que colocar IO secuencial en un huso con IO aleatorio hace que IO secuencial sea aleatorio. Puede parecer que sus discos de registro de transacciones no están sudando porque está viendo operaciones secuenciales de E / S. Las lecturas y escrituras secuenciales en un volumen RAID-1 serán bastante rápidas, por lo que si se basa en "no sudar" en la longitud de la cola del disco, por ejemplo, no está entendiendo toda la historia.

Mida o calcule los IOPS aleatorios máximos posibles para el volumen de destino previsto, tome una línea base de la carga de trabajo actual en ese volumen y luego decida si tiene suficiente margen para colocar esos IOPS de registro de transacciones en el IO aleatorio restante en el volumen de destino. Además, asegúrese de presupuestar el espacio necesario para la carga de trabajo (obviamente). Si está tan inclinado, incorpore un porcentaje de "espacio libre" adicional en su carga de trabajo de IO / asignación de espacio.

Continúe con esta metodología para todas las demás cargas de trabajo que desea poner en el volumen RAID-10 de destino. Si se queda sin IOPS al azar, entonces está acumulando demasiado en el volumen: agregue más discos o ponga parte de la carga de trabajo en volúmenes dedicados. Si te quedas sin espacio, agrega más discos.

Recientemente he leído más artículos que dicen que RAID 5 es una mala forma de confiabilidad. Lo creo más después de que un disco se estropeó en una matriz RAID 5, reemplazó la unidad y no se pudo recuperar porque un segundo disco tenía un error de lectura latente irrecuperable que nos obligó a formatear y restaurar desde la copia de seguridad.

A medida que las unidades se hacen más grandes, las probabilidades de tener un error de lectura irrecuperable no detectado en estos discos enormes también aumentan, y con RAID 5 la confiabilidad simplemente ya no es suficiente. Si no está duplicando, aparentemente el consejo es ir con RAID 10.

A menos que esté haciendo algo que sea muy sensible a los problemas de velocidad, no me preocuparía dividir las cosas en arreglos pequeños o algo así. Póngalo en un RAID 10 y vea si su rendimiento está a la altura. Con el almacenamiento en caché y la memoria adecuados en el sistema, debería estar bien. Los números para los puntos de referencia nunca serán lo que realmente obtendrá porque depende de su uso real, carga real, rendimiento de la unidad de disco, almacenamiento en caché del controlador, almacenamiento en caché del disco, fragmentación, etc.

La mejor regla general es simplificar la configuración tanto como sea posible porque incluso si pasa un día o una semana sudando por esta configuración en un año o dos, tendrá que solucionar algún problema en este servidor que se irá te preguntas por qué lo configuraste como lo hiciste si agregaste una complejidad innecesaria a la configuración.

¿Qué tan predecible desea que sean las latencias para sus aplicaciones?

Digamos, por ejemplo, que tiene una aplicación que es realmente sensible a la latencia y comparte un sistema de archivos con su base de datos financiera. Al cierre fiscal, de repente recibe llamadas sobre el tiempo de espera de la aplicación sensible a la latencia. ¿Cómo vas a resolver eso?

Por otro lado, soy un gran admirador de simplificar todo, por lo que verificaría que no tenga requisitos excepcionales y consolidaría y simplificaría sus configuraciones si sus requisitos no caen en ningún caso especial extraño.

Seguro Por qué no. Lo importante es que recuerde construir correctamente su gran matriz de discos múltiples, no se equivoque y tendrá un largo tiempo de reconstrucción.

RAID 10 viene en 2 sabores:

• RAID 1 + 0 donde construye 2 matrices RAID 1 y luego las separa.
• RAID 0 + 1 donde construye 2 matrices RAID 0, luego las refleja.

Una vez que un disco muere, en uno solo tendrás que reconstruir una sola matriz raid1. Con el otro tendrás que reconstruir toda la matriz raid0.