Configuración de unidad óptima para SQL Server 2008R2

19

Tengo un servidor de base de datos bastante ocupado que ejecuta SQL Server 2008 R2 que tiene la siguiente configuración:

  • SATA RAID 1 (2 unidades) - SO / Programas
  • SAS RAID 10 (4 unidades) - Archivos de base de datos SQL (datos y registros)
  • SAS RAID 1 (2 unidades) - TempDB (datos y registros)

Suponiendo que no puedo agregar unidades adicionales a este servidor, ¿he hecho el mejor uso de la configuración que tengo disponible? ¿O debería considerar otro esquema aquí donde los registros están aislados de los archivos de datos, por ejemplo?

Actualizar:

Para aquellos que solicitaron más detalles de hardware:

  • Las unidades SATA (utilizadas para la partición OS / Programa) son: WD 7200 RPM 3 Gb / s SATA de 3,5 pulgadas
  • Las unidades SAS utilizadas en las otras matrices son: Seagate 15K RPM 6 Gb / s SAS de 3.5 pulgadas
  • El controlador RAID utilizado es un puerto LSI 9260-8i SAS / SATA de 6 Gb 8

Actualización 2:

En base a la retroalimentación que he recibido, parece que tengo las siguientes opciones viables para elegir - Voy a conceder la recompensa a alguien que me puede decir que es probable que ser el mejor en el ambiente que he descrito:

  1. Deja todo como está; probablemente no lo haré mucho mejor
  2. Muevo mis 2 unidades SAS RAID 1 a mi matriz RAID 10 existente para que se componga de 6 discos en total
  3. Mover mis archivos de registro al SAS RAID 1 y / o reubicar TempDB (datos o registros) de nuevo al RAID 10
sql-server hardware DanP
fuente
Su segunda actualización hace exactamente las mismas preguntas que su pregunta original, por lo que se aplica la respuesta original. "... que probablemente sea el mejor en el entorno que he descrito" ... no nos ha mostrado ningún análisis de la carga de trabajo, solo que está "bastante ocupado", así que nuevamente se aplica la misma respuesta .
Mark Storey-Smith
Con NVMe de alto rendimiento y otros discos SSD en el mercado, el RAID ya no es muy importante desde la perspectiva de las mejores prácticas de configuración de disco del servidor SQL . Las agrupaciones de discos (espacios de almacenamiento) son el camino a seguir. Sin embargo, deberá separar lógicamente los volúmenes para solucionar mejor los problemas de rendimiento relacionados con el disco.
Faces Of IT

Respuestas:

14

Las variantes de esta pregunta aparecen semi-regularmente:

También hay peleas ocasionales sobre la "mejor práctica" de separación de datos / registros.

Sin un análisis más detallado de lo que está haciendo este servidor, se aplica el mismo consejo que se dio anteriormente.

  • RAID 1 para SO
  • RAID 10 (6 discos) para datos / registros / tempdb

Rara vez hay algún punto en una división con tan pocos husos disponibles. Una matriz única con una mayor capacidad de IOP típicamente absorberá los bultos y protuberancias de su carga de trabajo mejor que 2 matrices más pequeñas.

Una variante que vale la pena probar es poner tempdb en la unidad del sistema operativo. Solo hágalo si tiene una carga de trabajo representativa que pueda reproducir repetidamente, para garantizar una comparación equitativa de la configuración. Si opta por este arreglo en producción, asegúrese de que el crecimiento de tempdb esté restringido para no consumir inadvertidamente todo el espacio libre en la unidad del sistema operativo.

Dado que las unidades de su sistema operativo son montañas rusas de 7200 RPM, me sorprendería si tempdb en la configuración de la unidad del sistema operativo tuviera algún beneficio.

Mark Storey-Smith
fuente
7

Todo depende de su carga de trabajo, pero con solo 6 unidades limita sus opciones. Si su carga de trabajo no depende en gran medida de tempdb para cosas como clases, tablas hash y aislamiento de instantáneas, entonces podría ser mejor usar las 6 unidades SAS juntas en RAID 10. Sin embargo, si conoce o tiene las métricas para demostrar que tempdb se utiliza mucho, entonces debe mantenerlo separado como lo ha hecho.

Patrick Keisler
fuente
Gracias por la respuesta, cambiar la configuración de los rangos (desafortunadamente) no es una opción ya que este servidor está en producción. Tengo curiosidad por cambiar el tempdb de nuevo al RAID 10 y poner todos los archivos de registro en el RAID 1, ¿es esta una opción inteligente?
DanP
2
Recuerde que SQL Server necesita escribir físicamente todas las transacciones en el registro como parte de la confirmación, por lo que desea el rendimiento de escritura más rápido posible dentro de su configuración. RAID 10 ofrece un mejor rendimiento de escritura que RAID 1, por lo que dejaría los registros en el volumen más rápido.
Patrick Keisler
2

Depende mucho de lo que quiera decir con "muy ocupado": diferentes patrones de carga de trabajo (escribir pesado o no, operaciones masivas comunes o no, nivel de acceso concurrente, por nombrar solo tres de las muchas variables) pueden tener un efecto drástico en el rendimiento de cualquier disposición de husillo dada.

Para una situación grave de escritura, separar los registros de los datos puede hacer una diferencia significativa ya que cada escritura implica actualizar tanto el registro como los archivos de datos, por lo que implica una buena cantidad de volteo de cabeza adicional si ambos conjuntos de archivos están en el mismo conjunto de ejes .

Sin más referencia a su carga de trabajo (y la especificación de esas unidades y cualquier controlador que esté entre ellas y la máquina), me inclinaría por tres volúmenes: uno para programas OS + y tempdb (datos), uno para DB principal datos, y el tercero para registros (tempdb y DBs principales).

Por supuesto, si sus cargas de trabajo son muy ligeras en las operaciones de escritura, entonces no debería pasar demasiado tiempo preocupándose por mantener separados los datos y los registros, ya que hará poca diferencia en el rendimiento y dedicar un volumen completo para ellos sería un desperdicio bastante disponible. espacio.

David Spillett
fuente
Ciertamente describiría nuestro entorno como uno de "escritura pesada": actualizaré mi pregunta con especificaciones de hardware más detalladas el lunes.
DanP
¿Alguna idea sobre la cantidad de unidades que tiene OP? Estoy pensando más en el Raid 1 que tiene para los archivos de registro. Eso no suena como una gran opción para propósitos de escritura, y los archivos de registro AFAIK no son de lectura limitada, sino de escritura ...
Marian
He agregado especificaciones adicionales sobre el hardware de la máquina.
DanP
1
Este malentendido puede estar en la raíz de muchos de los discursos de separación de datos / registros, así que disculpe, pero lo voy a mencionar. "... ya que cada escritura implica actualizar tanto el registro como los archivos de datos" - no, no lo hace. Las escrituras en las páginas de datos ocurren en el punto de control, no en cada modificación.
Mark Storey-Smith
1
@DavidSpillett Es cierto, siempre habrá casos en los que la división sea beneficiosa. La clave es que usted probó y validó que la configuración fue beneficiosa para esa carga de trabajo en particular.
Mark Storey-Smith
2

La respuesta real depende de sus necesidades, pero generalmente "colocar datos e iniciar sesión en diferentes matrices" es de mayor importancia que "colocar tempdb en su propia matriz".

Dada la cantidad de unidades que tiene disponibles, mi punto de partida sería:

  1. Dos unidades, RAID 1: sistema operativo, ejecutables, archivo de paginación.
  2. Cuatro unidades, RAID 5: todos los archivos de datos (alternativamente, RAID 1 + 0)
  3. Dos unidades, RAID 1: todos los archivos de registro

Lo que debe hacer es usar SQLIO para probar el rendimiento de diferentes configuraciones de unidades.

Caminante de piedra verde
fuente
Esto definitivamente representa el "otro lado" del consejo que he leído. Desearía que hubiera un método definitivo para determinar cuál de las opciones sería mejor sin recurrir a "probarlo" en un entorno de producción.
DanP
2
@DanP Bueno, personalmente hubiera seguido el consejo de Mark y hubiera elegido un RAID10 con el resto de las unidades (excepto el sistema operativo). Los archivos de registro son intensivos en escritura y necesitan un mejor rendimiento que el que RAID 1 tiene para ofrecer, hasta donde creo. Pero no soy un experto en hardware. Solo mis 2 centavos.
Marian
2
Debo mencionar que mi opinión proviene solo de la experiencia de una migración fallida (más o menos) anterior a un mejor servidor, pero con un peor rendimiento. Nunca probamos una carga real en este nuevo servidor, nunca tuvimos la oportunidad, el servidor no estaba listo a tiempo. Resulta que las pruebas del servidor ANTES de migrar a producción deberían ser OBLIGATORIAS. Perdón por el énfasis. Entonces mi mantra para todas las migraciones / actualizaciones es: PRUEBA, PRUEBA, PRUEBA, ... prueba lo más posible.
Marian
1
No estoy seguro de si comenzar con RAID 5 o SQLIOSIM ... sigamos con el último, ya que el primero habla por sí mismo. SQLIOSIM es una herramienta de prueba de corrección y estrés , no es una herramienta de prueba de rendimiento o carga. No tiene absolutamente ningún lugar en la comparación del rendimiento de config-X vs config-Y para workload-Z. Todo lo que le diría es qué tan bien config-X funciona contra config-Y en una ejecución SQLIOSIM. Si desea comparar el rendimiento de workload-Z, pruebe workload-Z.
Mark Storey-Smith
1
@GreenstoneWalker "RAID1 es más rápido para escribir que RAID1 + 0" no tiene sentido. ¿De dónde vino esta idea?
Mark Storey-Smith
-1

Dependiendo de para qué esté utilizando la base de datos (OLTP vs almacenamiento), su configuración parece una buena configuración general. Si tuviera más discos, tendría más opciones.

Podría obtener un mejor rendimiento si cambiara el disco de su TempDB a RAID 0 (stripe). Aumenta su riesgo de falla, pero dado que TempDB solo almacena datos en la memoria intermedia, no puede experimentar la pérdida de datos. Entonces, la mayoría de la gente considera que es una compensación razonable. Solo guarde un repuesto (o un repuesto en caliente).

Una cosa que no mencionó, pero que podría probar (si aún no lo ha hecho): Microsoft recomienda dividir su TempDB en varios archivos (uno por CPU). Por supuesto, es mejor si están en discos separados, pero simplemente tener archivos separados ayuda. http://msdn.microsoft.com/en-us/library/ms175527(v=SQL.105).aspx

TimG
fuente
44
Tempdb se usa para muchas cosas, pero no lo trate como una base de datos desechable y no lo coloque en un RAID 0. Tenga en cuenta que si ese volumen RAID 0 falla, SQL Server no podrá iniciarse.
Patrick Keisler
De hecho, he creado una base de datos temporal por núcleo como se sugiere, pero gracias por plantear ese punto también :)
DanP
1
Bueno, estas sugerencias no son muy buenas y no son apropiadas para todos los entornos. El primero es mencionado por @PatrickKeisler anteriormente. El segundo es un mito que Paul Randal desmintió hace algún tiempo. El artículo es este: un mito de DBA de SQL Server al día: (30/12) tempdb siempre debe tener un archivo de datos por núcleo de procesador . Entonces, la documentación de MS puede estar equivocada, no la tome de memoria.
Marian
2
"dado que TempDB solo almacena datos, no puede experimentar la pérdida de datos" ... y estoy seguro de que los usuarios del sistema apreciarán que durante las X horas de tiempo de inactividad que sufren mientras a) las operaciones cavan en el sótano por un disco de reemplazo o b) un DBA intenta explicarle al servicio de asistencia cómo mover tempdb, desde su teléfono móvil.
Mark Storey-Smith