¿Cómo debo configurar la matriz RAID de unidades SSD en mi servidor SQL?

14

Estoy creando un Servidor SQL con 48 GB de RAM, 1 CPU y 8 unidades SSD SATA III (6 GB / s) (128 GB Crucial m4) y un controlador LSI MegaRAID (SAS 9265-8i). Espero que la carga de trabajo típica se lea principalmente. Habrá algunos períodos de mayor actividad de escritura (sincronizaciones de datos por hora con proveedores de datos de terceros, copias de seguridad nocturnas), pero sospecho que la relación de lectura / escritura típica es de aproximadamente 90% de lecturas / 10% de escrituras.

Opción 1:
Unidad lógica C: - RAID 1 (2 unidades físicas) -
Unidad lógica del sistema operativo D: - RAID 10 (6 unidades físicas) - Archivos DB / logs / tempdb / backups?

O

Opción 2:
Unidad lógica C: - RAID 1 (2 unidades físicas) -
Unidad lógica del sistema operativo D: - RAID 1 (2 unidades físicas) - Archivos Db
Unidad lógica E: - RAID 1 (2 unidades físicas) - ¿archivos de registro / copias de seguridad?
Unidad lógica F: - RAID 1 (2 unidades físicas) - tempdb

O

Opción 3: ¿
Otras sugerencias?

Estoy pensando que la opción 1 me daría un mejor rendimiento, ya que toda la actividad de la base de datos se dividiría en 3 unidades (y se reflejaría en las otras 3 en la matriz), aunque la opción 2 parece imitar la sabiduría convencional (que parece aplicarse más a la mecánica unidades que SSD). Parece que Stack Overflow se ha ido con la opción 1 .

Supongo que con SSD está bien poner todo en una sola unidad lógica ya que su servidor probablemente tenga más CPU en lugar de E / S en ese momento.

Otra pregunta que tengo es ¿dónde debo colocar las copias de seguridad nocturnas? No queremos que las copias de seguridad ralenticen el resto del servidor SQL, y supongo que escribir las copias de seguridad en la misma ubicación que los registros es una buena práctica porque el comportamiento de lectura / escritura en ambos casos es escritura secuencial.

sql-server configuration

— Robbie
fuente

Una vez creí que la distribución lógica era beneficiosa, pero después de una investigación bastante extensa (Michael aún puede tener algo de ella), llegamos a la conclusión de que la distribución lógica al nivel objetivo no mejoró el rendimiento. Entonces, si estuviéramos hablando de un disco físico (giratorio) y quisieras 8 archivos de datos para aprovechar la afinidad central, no importaba si eran 8 archivos en un solo volumen lógico (en el mismo disco físico) o si corta 8 particiones lógicas para esos 8 archivos (en el mismo disco físico). Creo que lo encontrará similar cortando lógicamente su SSD

— Eric Higgins

9

La sabiduría convencional sobre RAID no se aplica bien a los SSD. Realmente no necesitan rayas (RAID0). Son propensos a fallas por diseño, pero RAID-1 generalmente no es la respuesta correcta para SSD por dos razones: a) es un desperdicio, reduce a la mitad la capacidad de la matriz SSD (y son caros) y 2) las características de falla de SSD conducen hacia ambas unidades en el espejo para fallar a intervalos muy cercanos (es decir, fallas correlacionadas) y así inutilizar toda la matriz. Vea RAID diferencial: repensar RAID para la confiabilidad de SSD para una discusión más larga. Algunos han recomendado usar Raid-6 para SSD.

Además, la sabiduría convencional del diseño de archivos de SQL Server no se aplica a los SSD. Le recomendaría que vea SQL en SSD: Hot and Crazy Love y revise los enlaces de referencia en esta respuesta .

— Remus Rusanu
fuente

Buen punto, con RAID 10, probablemente soy más vulnerable a fallas correlacionadas. Gracias por el enlace RAID diferencial.

— Robbie

8

El enfoque estándar de separar los patrones de E / S aleatorios para datos de la secuencia de registros simplemente no se aplica a los SSD, por lo que elegiría su opción 1 con advertencias:

Las copias de seguridad DEBEN realizarse en una máquina separada. No tiene mucho sentido tener copias de seguridad a las que no pueda acceder en caso de que el servidor se desactive.
Hay cierto valor en separar los datos y las unidades de registro, de modo que una falla de la matriz de datos le permitiría tomar una cola de la copia de seguridad del registro.
Tenga en cuenta que no tiene un repuesto caliente.
Tenga en cuenta que tiene unidades de nivel de consumidor. No asuma que serán tan confiables como los equivalentes empresariales a un costo múltiple.
Mire el entretenido y muy informativo SQL en SSD: Hot and Crazy Love de Brent Ozar.

El problema de separar los registros de los datos donde se usan SSD es una cuestión de RPO (objetivo de punto de recuperación) para el sistema, en lugar de rendimiento. Si el RPO se define en minutos, vaya con una matriz compartida y realice copias de seguridad de registros cada [RPO] minutos. Si el RPO se define en segundos, vaya con matrices separadas.

Para ser honesto, si el RPO era ajustado, conservaría SSD para la matriz de datos y usaría un par de hiladores confiables caros (empresariales) para el registro.

— Mark Storey-Smith
fuente

Las copias de seguridad también se copian en una máquina separada. Se crean en la máquina local para que pueda usar SQL Compare / Data Compare y revertir los cambios en caso de regresión / error del usuario.

— Robbie

Además, el RPO se define en minutos (creo que incluso en los 10 minutos sería aceptable que mi escenario sea completamente honesto). La publicación Hot & Crazy Love me tiene pensando en fallas correlacionadas. En mi experiencia limitada, he tenido más fallas en la placa base y fallas totales del sistema (la fuente de alimentación / la sobretensión fríe todo) y luego fallas en la unidad, por lo que todavía estoy tratando de determinar cuál sería el nivel más rentable de paranoia / prevención.

— Robbie

1

Debe ir con la opción 2 de la siguiente manera:

Logical Drive - RAID 1 (2 physical drives)
 1 partition C: OS
 2 partition D: backups / log files
Logical Drive E: - RAID 1 (2 physical drives) - DATA files
Logical Drive F: - RAID 1 (2 physical drives) - INDEX files
Logical Drive G: - RAID 1 (2 physical drives) - tempdb

Al separar sus datos e índices en 2 archivos de datos diferentes que luego se almacenan en 2 unidades lógicas físicas diferentes, obtendría un gran aumento en el disco io simplemente porque cuando realiza una consulta, tendría un disco girando para los datos de su tabla y otro girando para su índice al mismo tiempo.

Deje tempdb separado de sus copias de seguridad también porque muchas cosas suceden allí también. No mezcle sus copias de seguridad y su archivo de datos. a pesar de que las copias de seguridad no se realizan a diario, cuando se producen reciben un gran impacto en su IO. según su negocio y el uso de su base de datos, algunas personas o MUCHAS personas podrían quejarse durante el tiempo de respaldo.

Espero que esto ayude

— Nicolas de Fontenay
fuente

66

Disparates. Estos son SSD, no spinners.

— Mark Storey-Smith

No es una tontería, incluso con SDD hay una serie de rendimiento alcanzado de esa manera, aunque no tanto.

— Nicolas de Fontenay

2

Incluso con los spinners, la separación de los datos de los índices no tiene valor hasta que juegues en territorio SQLCAT. El caso para separar tempdb nunca es claro y muy raramente se aplica con un número tan pequeño de discos.

— Mark Storey-Smith