Algo que siempre no está demás saber, algunas reglas genéricas
en cuanto a distribución y separación de discos físicos para diseño de
proyectos con Bases de Datos MS SQL Server.
Se recomienda:
1) Discos para el Sistema Operativo: El sistema operativo debe alojarse en sus propios discos individuales, con tolerancia a fallas. Mínimo Raid 1 (2 discos)
2) Discos para los Datos: La "data" debe almacenarse en la cantidad de discos que haya determinado el estudio previo de "capacity planning" para el hoy, y considerar el crecimiento vegetativo para 1 año y 3 ó 5 años. Sin embargo, estos discos físicos deben ser separados del resto y con su propia tolerancia a fallas. Por otra parte se debe determinar si la BD es del tipo OLTP o del tipo OLAP, es decir, si tiene una BD con una proporción similar de lecturas/escrituras, se habla de que es una BD tipo OLTP. Por el otro lado si la BD tiene una proporción marcada a las lecturas (del orden 90% ó superior) se habla que es del tipo OLAP, o sea data mayoritariamente de lectura, quizás para warehousing o reporting o históricas. Y por último se debe medir el caudal de datos a servir (en Mbps) y la cantidad de operaciones de entrada/salida, o IOps (operaciones de I/O por segundo). Una vez obtenidos esos datos, los discos para data OLTP debieran organizarse en Raid 1+0, cada par de discos espejados y éstos expandidos. Y la cantidad de brazos (o pares de brazos) en raid 0, vienen determinados por los IOps que se desee alcanzar.
Así si determinamos que cada disco físico tiene un rendimiento óptimo de 50 IOps (típico rendimiento de un disco IBM 15k u320), y a la vez medimos que la BD tiene un caudal de 200 IOps (una base de poca transaccionalidad), entonces para colocar esa data en Raid 1+0 necesitaremos 10 discos, ó 5 pares de discos en raid 1, todos los pares expandidos en raid 0. A su vez, si determinamos que el caudal de data es del menos de 300 Mbps, con una sola tarjeta controladora U320 SCSI nos bastará. Con esa cantidad de brazos y con esa tarjeta, estamos asegurando que el cuello de botella no será jamás el acceso a disco y no se producirá encolamiento en nuestra BD. (mínimo se necesitarán 4 discos, 2 pares espejados y expandidos, siempre y cuando se alcance la cantidad de espacio mínimo también)
Para la data OLAP, los discos debieran organizarse simplemente en Raid 5. ¿Por qué no usamos Raid 5 en data OLTP ?, porque se producen operaciones adicionales de escritura de CRC en los raid 5, lo que redunda en fallas de performance cuando las cabezas de los discos tienen mucho movimiento. En cambio, como en Raid 5, la lectura está libre de CRC checking, no afecta la performance de lectura y brinda un excelente tolerancia a fallas de hasta 1 disco. Recordemos que necesitaremos mínimo 3 discos físicos para componer un Raid 5. (*consideraciones de IOps y de Mbps pueden también realizarse)
3) Discos para el Log de Transacciones: En SQL Server el log de transacciones se escribe en forma secuencial cada vez que se produce un checkpoint, por lo que se considera que también debe tener sus discos físicos separados, para evitar que la cabeza del disco se mueva de lugar en que quedó. Mínimo se debe considerar una tolerancia a fallas de Raid 1 (2 discos). (ojo que esto es necesario sólo para OLTP)
4) Discos para la base TEMPDB: En SQL Server 2005 se realiza un uso exhaustivo de esta base de datos, en lo que se refiere a ordenamientos y a datos temporales. De hecho todas las bases de la instancia ocupan la misma TEMPDB (y cada instancia tiene su propia TEMPDB), por lo que no estaría mal considerar también ejes o brazos de disco físico separados para su uso exclusivo. Aquí se debe hacer las mismas consideraciones de IOps y de Mbps para determinar el mejor Raid 1+0. (por lo que se asume unos 4 discos mínimo, 2 pares espejados cada uno y expandidos) (*aparte se recomienda crear tantas TEMPDB como procesadores tenga el servidor, esto porque es el CPU el que realiza los sorts). (ojo que esto sólo es necesario para OLTP)
5) Otros Lujos con OLTP: Existen otras recomendaciones de separación de discos físicos para OLTP, como la separación de los índices en sus propios ejes de discos para separar la carga de los discos de data y maximizar el rendimiento de los seeks de índices. O bien la utilización de filegroups o tablas particionadas en discos más baratos (como SATA) para alojar quizás data histórica o de uso muy infrecuente. Eso es ya criterio y ahorro del diseñador.
Resumiendo, tenemos 2 casos :
1) Caso BD OLTP: 2 discos S.O. (raid1) + 4 discos para Data (raid 10) + 2 discos para TrxLog (raid1) + 4 discos para Tempdb (raid10) = mínimo 12 discos + discos necesarios para un IOps óptimo.-
2) Caso BD OLAP = 2 discos S.O. (raid1) + 3 discos para Data (raid 5) = 5 discos
y en ambos casos sumaremos la cantidad de discos para cuadrar el espacio físico y las tarjetas controladoras para un rendimiento óptimo del caudal de datos en Mbps.
* Nota: estas consideraciones de diseño de capacidad de discos en forma genérica también pueden ser aplicadas para Bases de Datos Oracle o bien MYSQL o cualquier otra.
NECESITAS MÁS AYUDA CON ESTO? ¿TIENES DUDAS? Entonces abónate con el servicio de soporte en línea (Chat) o deja una donación, gustoso te atenderemos. (haz click aquí para ir al link de subscripción del soporte chat)
Acá puede comprar un estudio de caso REAL de Capacidad de SQL Server completamente explicado, gráficos y cálculos a sólo USD$ 500
| buy |
 |
Espero sea de su utilidad este artículo, muchas gracias Amigos por leerme, y no se olviden de apoyarme con sus donaciones!!
