Archivos de SQL Server Local o NAS o SAN?

Tengo que instalar un nuevo servidor con SQL Server 2008. ¿Qué me recomiendan, un servidor con Raid 10 o los archivos en un NAS?

¿Qué pasa con iSCSI debería usarlo?

¿Qué hay de SAN?

El servidor tiene 4 Gb de RAM y ese archivo de base de datos es de aproximadamente 2 GB.

Para aclararme hoy, el servidor no tiene RAID, tengo que implementar algún tipo de estrategia para que, si sucede algo, pueda tener mis archivos seguros, entonces ¿Qué debo elegir Archivos locales, NAS, SAN? ¿Qué opción tiene el mayor rendimiento, cuál es la más segura?

NAS

Definitivamente no es NAS para SQL Server. SMB / CIFS no tiene soporte adecuado para el bloqueo de archivos para soportar un DBMS (al menos no lo hizo hace unos años, ca. 2002-2003). Tenga en cuenta que NFS sí lo hace y que puede hacerlo con Oracle en un servidor NFS. Sin embargo, SQL Server en un recurso compartido CIFS no es confiable debido a las limitaciones del protocolo. Es posible que ni siquiera le permita colocar archivos en recursos compartidos montados en CIFS.

SAN

Esto es bueno para aplicaciones transaccionales, ya que el caché en los controladores RAID puede absorber conjuntos de trabajo bastante grandes. Los controladores RAID SAN generalmente admitirán más caché que los controladores RAID basados ​​en host, particularmente en el kit de gama alta donde un controlador RAID podría ser una caja multiprocesador que es tan potente como un servidor.

Las SAN con controladores duales también tienen una arquitectura sin un solo punto de falla y ofrecen muchas opciones de respaldo en caliente. Esto los convierte en una victoria desde una perspectiva de manejabilidad y confiabilidad. Sin embargo, son caros y limitados para la transmisión de volúmenes de datos, aunque es poco probable que este último sea un problema en un sistema transaccional.

Para los sistemas operativos, las SAN son casi siempre la mejor opción si están disponibles. También se pueden compartir entre varios servidores que ejecutan sistemas de volumen medio bajo. Sin embargo, vienen con una etiqueta de precio que pone un límite inferior bastante sustancial en el sistema más pequeño con el que se puede usar la tecnología.

Conexión directa

En algunos casos, el almacenamiento de conexión directa es mejor. Una posibilidad son las aplicaciones de transmisión con restricción de ancho de banda, donde el número limitado de conexiones de canal de fibra limitará el ancho de banda disponible a menos de lo que podría ser posible con un controlador SAS de gama alta. Sin embargo, es probable que se trate de aplicaciones bastante especializadas, como almacenes de datos muy grandes donde una arquitectura de nada compartido puede proporcionar el mejor rendimiento.

De hecho, el almacenamiento de conexión directa a menudo es mejor que una SAN para sistemas de almacenamiento de datos por varias razones:

• Los almacenes de datos ponen grandes picos de carga transitoria en los subsistemas de disco. Esto los hace bastante antisociales en las SAN, ya que pueden afectar el rendimiento de otros sistemas en la SAN.

• El cuello de botella de transmisión antes mencionado.

• El almacenamiento de conexión directa es bastante más barato que el almacenamiento SAN.

Otro mercado para el almacenamiento de conexión directa es cuando vende a un mercado que no pagará suficiente dinero por una SAN. Esto es a menudo cierto en el caso de las aplicaciones vendidas a clientes de PYMES. Para un sistema de punto de venta o un sistema de gestión de prácticas que tendrá seis usuarios, una SAN probablemente sea exagerada. En este tipo de situación, un pequeño servidor de torre independiente con algunos discos internos es una solución mucho más adecuada.

Local o SAN es la única forma de mantener el rendimiento. En algunos casos, SAN puede ser más rápido que el disco local debido a la mayor caché de escritura y la configuración de rendimiento del disco paralelo.

Evite hacer E / S de archivos de alto rendimiento a través de recursos compartidos de Windows. Hay una gran cantidad de sobrecarga de protocolo que ralentizará drásticamente el rendimiento. Por ejemplo, hace años he medido que una transferencia de archivos de gran tamaño a través de una WAN fue ~ 50% más rápida usando FTP sobre recursos compartidos de Windows.

No uses NAS.

Utilice local (OK a mediano plazo con un buen controlador RAID) pero si el presupuesto lo permite, opte por una SAN decente. Con suerte, puede comenzar a "compartir" la SAN con otros sistemas y recuperar gran parte del desembolso inicial.

4 GB de RAM está bien para la mayoría de los sistemas siempre que sea un servidor SQL dedicado (y siempre debería serlo) Si aún no lo ha considerado, use el sistema operativo de 64 bits y el servidor SQL para poder agregar más RAM sin perder el tiempo con PAE / AWE.

También piense en la virtualización. ¿Vas a necesitar un servidor de prueba? Un servidor de desarrollo? Probar la instalación de SP1? (Shameless plus para publicaciones anteriores: sql-server-in-vmware )

Con un tamaño de base de datos de 2 Gb, no hay razón para considerar una SAN. Un NAS no funcionará, solo debe pensar en usar un NAS para copias de seguridad, de modo que no esté almacenando copias de seguridad en la misma máquina que sus datos, y es fácil hacer copias desde el NAS para el almacenamiento fuera del sitio.

Con una base de datos pequeña, solo use discos locales en un RAID 1 o RAID 10. Si su base de datos cabe en la RAM, no tiene que preocuparse tanto por el rendimiento de las E / S. Use ventanas de 64 bits y ponga 8 Gigs allí. Eso dejará mucho para el sistema operativo y le dará espacio para crecer.

Trabajo con sistemas que usan tanto discos RAID locales como SAN de conexión de fibra. La SAN parece funcionar mejor incluso con la primera como una máquina más nueva y más rápida. Creo que un factor importante es que la disposición del disco local es una sola unidad, por lo que SQL comparte la E / S del disco con el sistema operativo y el archivo de intercambio. Es probable que esto esté contribuyendo en gran medida a la resistencia.

Como @spoulson mencionó, la SAN puede proporcionar un rendimiento de disco mucho mejor. No solo es una unidad separada, sino que es probable que esté en un hardware de disco mucho más rápido.

En nuestro caso, estamos utilizando SAN porque proporciona un área de almacenamiento centralizado para los grupos de servicio VERITAS SQL Server de conmutación por error automática. Cuando falla la máquina principal, las unidades de Windows montadas en la SAN se vuelven a montar en la máquina de respaldo en caliente y el servidor vuelve a funcionar bastante rápido. Por supuesto, esto requiere un sistema similar a VERITAS para la gestión de grupos de servicio que podría estar fuera de su alcance.

La única advertencia con la que hemos luchado es que la asignación de espacio en disco SAN se maneja de manera conservadora. Como es costoso, no lo hacen por capricho. Con la SAN de EMC que utilizamos, no puede reclamar el espacio asignado sin descargar un LUN completo. Por lo tanto, si descubrimos que el espacio asignado es más de lo que necesitamos y queremos usar parte de ese espacio para otro LUN, no podemos simplemente reducir el de gran tamaño. Tenemos que soltarlo y reasignarlo. Esto no funciona tan bien en un entorno de producción.

Como otros han sugerido, evite NAS. También podría colocar sus archivos de datos en un disco duro externo USB.

Para una pequeña base de datos de 2GB, una SAN sería exagerada.

En términos generales, no desea que sus unidades SQL se compartan con ninguna otra aplicación. Del mismo modo, cuantos más ejes (discos) pueda distribuir sus archivos, mejor. Nuevamente, con una pequeña base de datos como la que usted describe, podrá ajustar todo lo que necesita en la RAM, por lo que el rendimiento del disco será un factor menos importante.

Dicho esto, no vaya y cree un solo volumen RAID-10 y ponga TODOS sus archivos de base de datos en él. Puede comenzar con algo simple como: Datos - 2x 73GB 15K RPM, Registros RAID1 - 2x 73GB 15K RPM, Copias de seguridad RAID1 - solo 7200 RPM grandes o un par en RAID1

Si tiene el presupuesto para actualizar, agregue otro volumen separado para TempDB (si realiza consultas complejas de informes / análisis) o dele al volumen Log más discos y configúrelo como RAID10 si su sistema es más transacción con un volumen alto de actualizaciones

Una SAN probablemente costaría entre 3 y 4 veces más que el almacenamiento conectado directamente para un número equivalente de unidades. Las SAN proporcionan muchas capacidades avanzadas para copias de seguridad / instantáneas, soporte de agrupamiento y migración y expansión de LUN. Si estos son importantes para usted, puede valer la pena el gasto adicional.

Descargo de responsabilidad: Hay muchos problemas serios con el almacenamiento de archivos de base de datos de SQL Server en un NAS. Todas las demás opciones son iguales, es correcto elegir la opción SAN. Una discusión detallada de los temas relevantes se encuentra en MS KB304261 . Sin embargo, este hilo se ha convertido en un problema para otras preguntas sobre SQL Server en un recurso compartido de red, prefiero publicar referencias al estado del soporte NAS en las versiones de SQL Server.

Muchas personas ahora experimentan con NAS con MS SQL.

Esto solía estar prohibido por defecto, sin embargo, uno podría levantar la restricción en MS SQL 2008 y MS SQL 2005. Desde MS SQL 2008 R2 no existe tal restricción.

En MS SQL 2005 y 2008, la clave es el indicador de rastreo que prohíbe el uso de recursos compartidos de red. Uno puede emitir

 DBCC TRACEON(1807, -1)
 CREATE DATABASE [test] ON  PRIMARY 
 ( NAME = N'test', FILENAME = N'\\storage\mssql_db\test.mdf' )

Más detalles en la publicación de septiembre de 2010 en el blog de MSDN de Varun Dhawan.

Al menos técnicamente, es posible ejecutar SQL Server en un NAS. La elección depende de muchos factores y no es difícil imaginar una situación en la que el almacenamiento de una base de datos esté fácilmente disponible en un NAS.