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 deben separarse los archivos SQL (archivos de datos, registros, temp)?
¿Es mejor RAID muchos discos duros y particionar el espacio o hacer múltiples RAID con menos discos para cada RAID?
¿Los datos y los archivos de registro deben estar en un tipo de RAID diferente?
¿Deberían ubicarse las bases de datos predeterminadas (maestra, msdb, etc.) en la C: o deberían estar en el mismo lugar que los otros archivos de datos / registro?
sql-server
raid
partition
Sean Howat
fuente
fuente
Esta es una gran pregunta "depende".
No puedo responder la pregunta de cómo crear las matrices RAID individuales para usted, 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 diversas bases de datos: OLTP (lectura / escritura) o DSS / DW (lectura en su mayoría). Para las cargas de trabajo de lectura / escritura, debe considerar RAID 1 o RAID 10 (RAID 1 + 0), ya que proporcionan redundancia y un excelente rendimiento de lectura / escritura. Para cargas de trabajo en su mayoría leídas, puede usar RAID 5. La razón por la cual 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 escritura principalmente, dependiendo de si está utilizando el registro de transacciones para cualquier cosa, por ejemplo, copias de seguridad de registros o replicación) y, por lo tanto, nunca deben colocarse en RAID 5.
Esto significa que para algunas bases de datos y cargas de trabajo, puede tener archivos de datos en RAID 5 y archivos de registro en RAID 1/10, y para otras bases de datos puede tener todo en RAID 1/10. Yendo más allá, si tiene una base de datos particionada, puede contener algunos datos de lectura y lectura / escritura, posiblemente incluso dentro de la misma tabla. Esto podría dividirse en grupos de archivos separados y luego cada grupo de archivos se colocaría 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 de E / S subyacente; por ejemplo, se puede requerir un mayor grado de separación para almacenar cosas en matrices RAID individuales que en una SAN.
Tempdb es un caso especial por sí solo, ya que generalmente es una base de datos muy cargada y debe almacenarse por separado de las otras bases de datos. Las bases de datos del sistema no se deben usar mucho y se pueden colocar en cualquier lugar siempre que haya redundancia.
Aquí hay un enlace a un documento que ayudé a escribir que debería ayudarlo: Diseño de almacenamiento de base de datos física . También asegúrese de que su subsistema de E / S pueda manejar la carga de trabajo anticipada; consulte este documento técnico: Prácticas recomendadas de E / S previas a la implementación . Finalmente, asegúrese de usar el tamaño de banda RAID correcto (generalmente 64 K o más en los sistemas más nuevos), el tamaño correcto de la unidad de asignación NTFS (generalmente 64 K) y que en los sistemas anteriores a Windows Server 2008, configure correctamente el desplazamiento de la partición del disco . Para obtener información sobre estos e indicadores 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 las correcciones de partición de disco, los tamaños de banda RAID y las unidades de asignación NTFS configuradas correctamente? .
Línea de Bototm: 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, es una gran lata de gusanos sobre cómo debe configurarlo y hay todo tipo de información contradictoria. Escribí una publicación de blog exhaustiva sobre la configuración del archivo de datos tempdb en Conceptos erróneos sobre TF 1118 .
fuente
La respuesta corta para los servidores que he configurado siempre ha sido
Registros en discos físicos separados, incursión 1 o 10 (franjas + reflejo)
Base de datos en discos propios, dependiendo de las necesidades de rendimiento, generalmente RAID5
Gran cantidad de caché en los controladores de banda
Preferiblemente pegue su sistema operativo y el archivo de paginación de Windows en una matriz separada nuevamente, generalmente solo un espejo (Raid 1). Esto mantiene separadas todas las operaciones de escritura para que el alto rendimiento no arrastre todo hacia abajo.
Lo que he experimentado en el pasado es que tener escrituras de bases de datos + escrituras de registros + escrituras de archivos de paginación empantanará una matriz Raid5 y el rendimiento se verá afectado en una cesta de mano. El problema es que su rendimiento estará bien 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.
fuente
Aquí hay muchachos de MSSQL mucho mejores 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. Para esto utilizamos 2 discos SAS 146GB 10krpm de 2.5 pulgadas, pero podría usar 2 discos SATA 7.2. Los datos deben estar en una matriz RAID 1/10, 5/50/6/60 RAID bastante rápida (10krpm o mejor) de cualquier tamaño que necesite: tenemos los nuestros en FC SAN LUN, generalmente en un grupo de discos de 'nivel 2' / 10krpm . Los registros deben estar en un par de matriz RAID 1 pequeño MUY RÁPIDO (15krpm) pequeño (¿10GB o menos?): Mantenemos el nuestro en FC SAN LUN, generalmente en un grupo de discos muy pequeño 'tier1' / 15krpm o en un 'tier0' / grupo ssd
De cualquier manera, desea que cada parte de estos en ejes / matrices separados para el rendimiento, por supuesto, todo funcionará en un solo disco, pero supongo que está buscando un equilibrio entre rendimiento y costo.
Almacenamos nuestro master / tempdb con nuestras bases de datos regulares, pero puede dividirlo en un LUN de matriz de datos separado.
Espero que esto ayude.
fuente