¿SAN con algunas unidades SSD o muchos discos duros anticuados?

Mi compañía está tratando de averiguar qué tipo de SAN comprar. Esto es específicamente para servidores de bases de datos que se están restringiendo a E / S (el almacenamiento es DAS en este momento, pero estamos llegando al límite de un solo servidor y también nos gustaría agregar clustering).

Necesitamos una solución que produzca alrededor de 3000 IOPS a largo plazo (actualmente tenemos un pico de alrededor de 1000 IOPS). La mayoría de las operaciones de nuestra base de datos son pequeñas lecturas / escrituras. Según las conversaciones con los ingenieros de HP y otros en línea, una HP P2000 con 24 SAS HD en una configuración RAID 10 ofrecerá poco menos de esa velocidad por ~ $ 20K. Agregar controladores y otros elementos para construir la SAN nos pone a la altura de nuestro presupuesto máximo de $ 30K.

Pero en línea, veo que muchas SSD SAS ofrecen velocidades de 80,000 IOPS +. ¿Es esto realista esperar? Si es así, ¿sería realista obtener un P2000 o un SAN de nivel de entrada similar y lanzar algunos SSD allí? Nuestras bases de datos son pequeñas, solo un par de TB en total. Si hiciéramos esto, tendríamos el dinero restante para comprar una segunda SAN para duplicación / conmutación por error, lo que parece prudente.

Puedo hablar sobre los detalles de lo que estás tratando de lograr. Honestamente, no consideraría un HP P2000 / MSA2000 de nivel de entrada para su propósito.

Estos dispositivos tienen muchas limitaciones y, desde la perspectiva del conjunto de características SAN, no son más que una caja de discos. Sin niveles, sin almacenamiento en caché inteligente, un máximo de 16 discos en un grupo de discos virtuales , capacidades bajas de IOPS, soporte SSD deficiente (especialmente en la unidad que seleccionó).

Usted tendría que intensificar a la HP MSA2040 a ver ninguna ventaja de rendimiento o de apoyo oficial con los SSD. Además, ¿realmente quieres usar iSCSI?

DAS puede ser su mejor opción si puede tolerar el almacenamiento local. El almacenamiento flash PCIe estará por debajo de su presupuesto, pero la capacidad deberá planificarse cuidadosamente.

¿Puede explicar las especificaciones de sus servidores reales? Marca / modelo, etc.

Si la agrupación es imprescindible, otra opción es hacer la unidad HP MSA2040, pero usar una unidad SAS en lugar de iSCSI. Esto es menos costoso que los otros modelos, le permite conectar 4-8 servidores, ofrece baja latencia y gran rendimiento, y aún puede admitir SSD. Incluso con los modelos Fiber o iSCSI, esta unidad le daría más flexibilidad que la que vinculó.

La regla general que uso para el disco IO es:

• 75 IOP por husillo para SATA.

• 150 IOP por husillo para FC / SAS

• 1500 IOP por husillo para SSD.

Además de los IOP por matriz, también considere los IOP por terabyte. No es raro terminar con una relación IOP por TB muy mala si se hace SATA + RAID6. Es posible que esto no suene demasiado, pero a menudo terminará con alguien que ve 'espacio libre' en una matriz y desea usarlo. Es común que las personas compren conciertos e ignoren iops, cuando realmente lo contrario es cierto en la mayoría de los sistemas empresariales.

Luego agregue el costo de penalización por escritura para RAID:

• 2 para RAID1, RAID1 + 0
• 4 para RAID5 (o 4)
• 6 para RAID6.

La penalización de escritura se puede mitigar parcialmente en grandes cachés de escritura grandes y en las circunstancias correctas. Si tiene muchas IO de escritura secuencial (como registros de DB) puede reducir esas penalizaciones de escritura en RAID 5 y 6 de manera bastante significativa. Si puede escribir una franja completa (por ejemplo, un bloque por huso), no tiene que leer para calcular la paridad.

Suponga un conjunto RAID 6 8 + 2. En funcionamiento normal para una sola escritura IO necesita:

• Lea el bloque 'actualizado'.
• Lee el primer bloque de paridad
• Lee el segundo bloque de paridad
• Recalcule la paridad.
• escriba todos los 3. (6 IOs).

Con una escritura de banda completa en caché, por ejemplo, 8 'fragmentos' consecutivos del tamaño de la banda RAID, puede calcular la paridad en todo el lote, sin necesidad de una lectura. Por lo tanto, solo necesita 10 escrituras, una para cada dato y dos paridades.

Esto hace que su penalización de escritura sea 1.2.

También debe tener en cuenta que escribir IO es fácil de almacenar en caché; no necesita tenerlo en el disco de inmediato. Funciona bajo una restricción de tiempo suave: siempre que sus escrituras entrantes en promedio no excedan la velocidad del eje, todo podrá ejecutarse a 'velocidad de caché'.

Read IO, por otro lado, sufre una restricción de tiempo difícil: no puede completar una lectura hasta que se hayan recuperado los datos. Los algoritmos de almacenamiento en caché de lectura y carga de caché se vuelven importantes en ese punto: los patrones de lectura predecibles (por ejemplo, secuenciales, como se obtendrían de la copia de seguridad) se pueden predecir y buscar previamente, pero los patrones de lectura aleatorios no.

Para las bases de datos, generalmente le sugiero que asuma que:

• la mayor parte de su 'base de datos' IO es de lectura aleatoria. (por ejemplo, malo para acceso aleatorio). Si puede pagar los gastos generales, RAID1 + 0 es bueno, porque los discos duplicados proporcionan dos fuentes de lecturas.

• la mayor parte de su 'log' IO es escritura secuencial. (por ejemplo, bueno para el almacenamiento en caché y, al contrario de lo que sugerirán muchos DBA, probablemente desee RAID50 en lugar de RAID10).

La relación de los dos es difícil es difícil de decir. Depende de lo que haga el DB.

Debido a que IO de lectura aleatoria es el peor de los casos para el almacenamiento en caché, es donde el SSD realmente entra en juego: muchos fabricantes no se molestan en almacenar en caché el SSD porque de todos modos tiene la misma velocidad. Entonces, especialmente para cosas como bases de datos temporales e índices, SSD ofrece un buen retorno de la inversión.

Tu análisis es bastante correcto.

Use algunos discos duros para muchos GB y muchos discos duros para algunas IOps.
Use algunos SSD para muchos IOP y muchos SSD para algunos GB

¿Cuál es más importante para ti? El espacio es el gran generador de costos para las soluciones SSD, ya que el precio por GB es mucho mayor. Si está hablando de una base de datos de 200 GB que necesita 4K IOP, un par de SSD lo llevará allí. O una matriz de 24 discos de unidades de 15K, que le deja mucho espacio para almacenamiento masivo.

La cantidad de IOps que realmente obtendrá de esos SSD varía mucho según la infraestructura de almacenamiento (ewwhite explicará eso), pero es razonable obtener ese tipo de velocidades. Especialmente con Raid10, donde no se calcula la paridad.

Recientemente construí un par de servidores de almacenamiento para mi empleador, usando el chasis Dell C2100, ejecutando FreeBSD 10.1 con doce unidades SATA empresariales de 2TB 7200rpm Western Digital "SE". Las unidades están en un único grupo ZFS que consta de dos dispositivos virtuales RAIDZ-2 de 6 unidades (vdevs). Adjunto al grupo hay un par de SSD Intel DC S3500 que están protegidos con supercap contra pérdida de energía, se usan como SLOG y L2ARC. Prueba de carga de este servidor sobre iSCSI, pude alcanzar 7500-8200 IOPS. Nuestro costo total, incluidos los discos duros, fue de aproximadamente $ 2700 por servidor.

En el tiempo en que estos sistemas basados ​​en BSD han estado funcionando, una de nuestras unidades HP MSA2012i SAN ha experimentado dos fallas en el controlador, y nuestra otra unidad MSA2012i ha dañado un gran volumen NTFS que requiere 12 horas de tiempo de inactividad para reparar.

Dell y HP le venden un 10% de hardware y un 90% de promesa de soporte que nunca podrá utilizar.