Estoy buscando algunos consejos sobre la mejor manera de configurar mis discos/particiones para SQL Server. Estas son algunas de mis principales preocupaciones:
¿Cómo se deben separar los archivos SQL (archivos de datos, registros, temperatura)?
¿Es mejor RAID de muchos discos duros y particionar el espacio o realizar varios RAID con menos discos para cada RAID?
¿Los archivos de datos y de registro deberían estar en un tipo de RAID diferente?
¿Las bases de datos predeterminadas (master,msdb, etc...) deberían estar ubicadas en C: o deberían estar en el mismo lugar que los otros archivos de datos/registro?
Respuesta1
Aquí hay una buena publicación de blog:http://sqlserveradvisor.blogspot.com/2009/03/sql-server-disk-configuration.html
Libro blanco sobre alineación de discos:http://msdn.microsoft.com/en-us/library/dd758814.aspx
En resumen, su sistema operativo debe estar en RAID 1, sus archivos de datos en RAID 10 (preferiblemente) y los archivos de registro en RAID 1.
Artículo sobre rendimiento de SQL:http://www.sql-server-performance.com/faq/raid_1_raid_5_p1.aspx
PDF con los 10 mejores consejos de rendimiento:http://www.stlssug.org/docs/Best_Practices_for_Performance.pdf
Recuerde también poner su TEMPDB en un disco separado por razones de rendimiento. Estoy seguro de que Paul Randal vendrá aquí y te dejará boquiabierto con el por qué en un momento.
MS dice por qué para tempdb:http://msdn.microsoft.com/en-us/library/ms175527.aspx
Respuesta2
Ésta es una gran pregunta del tipo "depende".
No puedo responder la pregunta sobre cómo crear matrices RAID individuales, ya que no soy un experto en almacenamiento, pero puedo ayudarlo con el resto.
Lo primero que debe considerar es cuál es la carga de trabajo en las distintas bases de datos: OLTP (lectura/escritura) o DSS/DW (lectura mayoritaria). Para cargas de trabajo de lectura/escritura, debería considerar RAID 1 o RAID 10 (RAID 1+0), ya que proporcionan redundancia y un excelente rendimiento de lectura/escritura. Para cargas de trabajo principalmente de lectura, puede usar RAID 5. La razón por la que RAID 5 no debe usarse para cargas de trabajo de lectura/escritura es que paga una penalización de rendimiento en las escrituras.
Los registros de transacciones, por su propia naturaleza, son de lectura/escritura (o principalmente de escritura, dependiendo de si está utilizando el registro de transacciones para algo, por ejemplo, copias de seguridad o replicación de registros) y, por lo tanto, nunca deben colocarse en RAID 5.
Esto significa que para algunas bases de datos y cargas de trabajo, es posible que tenga archivos de datos en RAID 5 y archivos de registro en RAID 1/10, y para otras bases de datos, es posible que tenga todo en RAID 1/10. Yendo más allá, si tiene una base de datos particionada, puede contener algunos datos de lectura mayoritaria y algunos de lectura/escritura, posiblemente incluso dentro de la misma tabla. Esto podría dividirse en grupos de archivos separados y luego colocar cada grupo de archivos en un nivel RAID apropiado.
La separación de las bases de datos reales nuevamente depende de la carga de trabajo y de las capacidades del subsistema IO subyacente: puede ser necesario un mayor grado de separación para almacenar cosas en matrices RAID individuales que en una SAN, por ejemplo.
Tempdb es un caso especial por sí solo, ya que normalmente es una base de datos muy cargada y debe almacenarse separada de las otras bases de datos. Las bases de datos del sistema no deben usarse mucho y pueden ubicarse en cualquier lugar siempre que haya redundancia.
Aquí hay un enlace a un documento técnico que ayudé a escribir y que debería ayudarlo:Diseño de almacenamiento de bases de datos físicas. También asegúrese de que su subsistema IO pueda manejar la carga de trabajo anticipada; consulte este documento técnico:Mejores prácticas de E/S previas a la implementación. Finalmente, asegúrese de utilizar el tamaño de banda RAID correcto (generalmente 64 K o superior en sistemas más nuevos), el tamaño de unidad de asignación NTFS correcto (generalmente 64 K) y que en sistemas anteriores a Windows Server 2008, configuró correctamente el desplazamiento de la partición del disco. . Para obtener información sobre estos y sugerencias para obtener más información sobre ellos y por qué debería configurarlos de esta manera, consulte esta publicación de blog:¿Están configurados correctamente las compensaciones de partición de disco, los tamaños de bandas RAID y las unidades de asignación NTFS?.
Línea inferior: conozca su carga de trabajo y las capacidades de su subsistema IO y luego implemente en consecuencia.
Espero que esto te sea útil.
PD: En lo que respecta a tempdb, hay una gran lata de gusanos sobre cómo configurarlo y hay todo tipo de información contradictoria. Escribí una publicación de blog completa sobre la configuración del archivo de datos tempdb enConceptos erróneos sobre TF 1118.
Respuesta3
La respuesta corta para los servidores que he configurado siempre ha sido
Registros en discos físicos separados, raid 1 o 10 (separación + duplicación)
Base de datos en discos propios, dependiendo de las necesidades de rendimiento normalmente RAID5
Mucho caché en los controladores raid
Preferiblemente vuelva a colocar su sistema operativo y el archivo de paginación de Windows en una matriz separada, generalmente solo un espejo (Raid 1). Esto mantiene todas las operaciones de escritura separadas para que el alto rendimiento no afecte todo.
Lo que he experimentado en el pasado es que tener escrituras de bases de datos + escrituras de registros + escrituras de archivos de paginación atascará una matriz Raid5 y el rendimiento se irá al diablo. El problema es que su rendimiento será bueno en pruebas, desarrollo, etc. Pero cuando entre en producción y el uso se dispare, este problema aparecerá "de la nada" y las quejas de los usuarios se dispararán.
Respuesta4
Hay chicos de MSSQL mucho mejores aquí que yo, pero en términos generales sugeriría lo siguiente;
Sistema operativo y código en C: - estos deberían ser los discos locales, deberían ser un par de matriz RAID1 - usamos 2 discos SAS de 2,5 pulgadas, 146 GB y 10 krpm para esto, pero podría usar 2 discos SATA 7.2. Los datos deben estar en una matriz RAID 1/10, 5/50/6/60 bastante rápida (10 krpm o mejor) del tamaño que necesite; mantenemos los nuestros en FC SAN LUN, generalmente en un grupo de discos de 'nivel 2'/10 krpm. . Los registros deben estar en un par de matrices RAID 1 pequeño MUY RÁPIDO (15 krpm) (¿10 GB o menos?) separado; mantenemos el nuestro en FC SAN LUN, generalmente en un grupo de discos muy pequeño de 'nivel 1'/15 krpm o en un 'nivel 0'/ grupo ssd.
De cualquier manera, desea que cada parte de estos esté en ejes/matrices separados para el rendimiento; por supuesto, todo funcionará con un solo disco, pero supongo que está buscando un equilibrio entre rendimiento y costo.
Almacenamos nuestro master/tempdb con nuestras bases de datos habituales, pero puede dividirlo en un LUN de matriz de datos independiente.
Espero que esto ayude.