it-swarm-es.com

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, debo usarlo?

¿Y SAN?

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

Para aclararme hoy que el servidor no tiene RAID, tengo que implementar algún tipo de estrategia para que, si algo sucede, 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?

15
Jedi Master Spooky

[~ # ~] nas [~ # ~]

Definitivamente no NAS para SQL Server. SMB/CIFS no tiene el soporte adecuado para el bloqueo de archivos para soportar un DBMS (al menos no lo tenía hace unos años, ca. 2002-2003). Tenga en cuenta que NFS ¡sí y, de hecho, puede hacer esto 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 las aplicaciones transaccionales ya que la caché de los controladores RAID puede absorber conjuntos de trabajo bastante grandes. SAN Los controladores RAID normalmente admitirán más caché que los controladores RAID basados ​​en host, particularmente en el kit de gama alta donde un controlador RAID puede ser una caja multiprocesador que es tan poderosa 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 ventaja desde una perspectiva de manejabilidad y confiabilidad. Sin embargo, son costosos y limitados para el flujo de volúmenes de datos, aunque es poco probable que esto ú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.

Adjunto directo

En algunos casos, lo mejor es el almacenamiento de archivos adjuntos directos. Una posibilidad son las aplicaciones de transmisión con restricciones 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 sería posible con un controlador SAS de alta gama). Sin embargo, es probable que Ser aplicaciones bastante especializadas, como almacenes de datos muy grandes, donde una arquitectura no compartido puede proporcionar el mejor rendimiento.

De hecho, el almacenamiento de archivos adjuntos directos suele ser mejor que un SAN para los sistemas de almacenamiento de datos por varias razones:

  • Los almacenes de datos generan grandes picos de carga transitorios 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 mencionado anteriormente.

  • El almacenamiento adjunto directo 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 suele ser cierto en el caso de las aplicaciones vendidas a clientes SMB. Para un sistema de punto de venta o un sistema de gestión de prácticas que tendrá seis usuarios, un SAN es probablemente En este tipo de situación, un pequeño servidor en torre independiente con algunos discos internos es una solución mucho más apropiada.

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 una mayor caché de escritura y una configuración de rendimiento de disco paralelo .

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

2
spoulson

No use NAS.

O use local (está bien a medio plazo con un buen controlador RAID) pero si el presupuesto lo permite, elija una SAN decente. Con suerte, puede comenzar a "compartir" el SAN con otros sistemas y recuperar gran parte del desembolso inicial.

4GB 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 un sistema operativo de 64 bits y un servidor SQL para que pueda arroje fácilmente más RAM sin perder el tiempo con cosas PAE/AWE.

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

1
Guy

Con un tamaño de base de datos de 2 Gb, no hay razón para considerar siquiera una SAN. A NAS no funcionará, solo debería pensar en usar un NAS para las copias de seguridad, por lo que no está almacenando copias de seguridad en la misma máquina que sus datos, y es fácil de hacer copias desde el NAS para almacenamiento externo.

Con una base de datos pequeña, simplemente 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 IO. Use 64- bit windows y ponga 8 Gigs allí. Eso dejará suficiente para el sistema operativo y le dará espacio para crecer.

1
Eric Z Beard

Trabajo con sistemas que utilizan tanto disco RAID local como SAN de conexión de fibra. El SAN parece funcionar mejor incluso con el primero 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 contribuya en gran medida a la resistencia.

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

En nuestro caso, estamos usando SAN porque proporciona un área de almacenamiento centralizada para los grupos de servicios de VERITAS SQL Server de conmutación por error automática. Cuando la máquina principal falla, las unidades de Windows montadas en SAN se vuelve a montar en la máquina de copia de seguridad en caliente y el servidor vuelve a funcionar con bastante rapidez.Por supuesto, esto requiere un sistema similar a VERITAS para la gestión de grupos de servicios que puede 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. Debido a que es costosa, no la distribuyen por capricho. Con la EMC SAN usamos, no puede recuperar el espacio asignado sin descargar un LUN completo. Por lo tanto, si encontramos que el espacio asignado es más de lo que necesitamos y queremos usar parte de ese espacio para otro LUN, no podemos simplemente encoja el de gran tamaño. Tenemos que eliminarlo y reasignarlo. Esto no funciona tan bien en un entorno de producción.

Como han sugerido otros, evite NAS. También puede guardar sus archivos de datos en un disco duro externo USB.

0
Peter

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

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 base de datos pequeña como la que describe, podrá colocar todo lo que necesita en la RAM, por lo que el rendimiento del disco será un factor menor.

Dicho esto, no cree un solo volumen RAID-10 y coloque TODOS los archivos de su base de datos en él. Puede comenzar con algo simple como: Datos - 2x 73GB 15K RPM, Registros RAID1 - 2x 73GB 15K RPM, Backups RAID1 - único grande 7200 RPM 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 proporcione más discos al volumen de registro y configúrelo como RAID10 si su sistema tiene más transacciones con un volumen alto de actualizaciones.

A SAN probablemente costaría entre 3 y 4 veces más que el almacenamiento de conexión directa para una cantidad equivalente de unidades. Las SAN brindan muchas capacidades avanzadas para copias de seguridad/instantáneas, soporte de agrupamiento y migración y expansión de LUN). Si son importantes para usted, puede valer la pena el gasto adicional.

0
Chris B

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

Muchas personas ahora experimentan con el uso de NAS con MS SQL.

Esto solía estar prohibido de forma predeterminada, sin embargo, se 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 la marca de seguimiento 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 publicación de septiembre de 201 en el blog de MSDN de Varun Dhawan.

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

0
Dmitri Chubarov