Pregunta

Quiero acceder a los archivos de la base de datos de mi servidor SQL en un almacenamiento INTEL SS4000-E. Es un almacenamiento NAS. ¿Podría ser posible trabajar con él como un almacenamiento para el servidor SQL 2000? Si no, ¿cuál es la mejor solución?

¿Fue útil?

Solución

Lo recomiendo enérgicamente.

Coloque sus archivos de datos localmente en el propio servidor, con unidades duplicadas RAID. Las razones son dobles:

  • SQL Server se ejecutará mucho más rápido para todos, excepto para las cargas de trabajo más pequeñas
  • SQL Server será mucho menos propenso a la corrupción en caso de que se rompa el enlace al NAS.

Use el NAS para almacenar copias de seguridad de su servidor SQL, no para alojar sus archivos de datos. No sé cuál será el tamaño de su base de datos, o cuál será su patrón de uso, por lo que no puedo decirle lo que DEBE tener. Como mínimo para una base de datos que llevará una carga significativa en un entorno de producción, recomendaría dos unidades lógicas (una para datos, una para su registro de transacciones), cada una de las cuales consiste en una matriz RAID 1 de las unidades más rápidas que puede manejar. comprar. Si eso es una exageración, ponga su base de datos en solo dos unidades físicas (una para el registro de transacciones y otra para los datos). Si incluso ESO está por encima del presupuesto, coloque sus datos en una sola unidad, realice una copia de seguridad con frecuencia. Pero si elige la solución NAS o de unidad única, en IMO, está confiando en el poder de la oración (lo que puede no ser algo malo, simplemente no es tan efectivo al diseñar bases de datos).

Tenga en cuenta que un NAS no es lo mismo que un SAN (en el que las personas suelen colocar archivos de base de datos). Por lo general, un NAS es mucho más lento y tiene mucho menos ancho de banda que una conexión SAN, que está diseñada para una confiabilidad muy alta, alta velocidad, administración avanzada y baja latencia. Un NAS está más orientado a reducir su costo de almacenamiento en red.

Otros consejos

Mi reacción instintiva: creo que estás enojado arriesgando tus datos en un NAS. La expectativa de SQL es un acceso ininterrumpido de baja latencia continua a su subsistema de almacenamiento. El NAS es casi seguro que no es nada de eso: usted, el almacenamiento local o SAN (en orden de rendimiento, simplicidad y, por lo tanto, preferencia), deja el NAS para el almacenamiento / respaldo de archivos sin conexión.

La siguiente KB enumera algunas de las restricciones y problemas que surgirían al tratar de usar un NAS con SQL, mientras que la KB abarca SQL 7 hasta 2005, gran parte de la información también se aplica a SQL 2008.

  

http://support.microsoft.com/kb/304261

local es casi siempre más rápido que el almacenamiento en red.

Su rendimiento para sql dependerá de cómo se definan sus objetos, archivos y grupos de archivos, y de cómo los consumidores usan los datos.

Bueno " mejor " significa diferentes cosas para diferentes personas, pero creo que " mejor " el rendimiento sería un TMS RAMSAN o un RAID de SSD ... etc

La mejor capacidad se lograría con un RAID de discos duros grandes ...

La mejor confiabilidad / seguridad de datos se lograría con la duplicación en muchas unidades, y copias de seguridad regulares (preferiblemente fuera del sitio) ...

Mejor disponibilidad ... No sé ... tal vez clonar el sistema y tener una copia de seguridad en caliente lista para funcionar en todo momento.

La mejor seguridad requeriría cifrado, pero principalmente limitar el acceso físico a la máquina (y sus copias de seguridad) es suficiente a menos que esté conectado a Internet.

Como señalan las otras respuestas, aquí habrá una penalización de rendimiento.

También vale la pena mencionar que estas cosas a veces implementan un caché de RAM para mejorar el rendimiento de E / S. Si ese es el caso y prueba esta configuración, el NAS debe estar en la misma protección de energía / UPS que el hardware del servidor. De lo contrario, en caso de un apagón, el NAS puede "perder" la parte del archivo en el caché. ay!

Puede funcionar, pero una SAN de fibra dedicada dedicada será mejor.

Por lo general, el local será más rápido, pero tiene un tamaño limitado y no se escalará fácilmente.

No estoy familiarizado con el hardware, pero inicialmente implementamos un almacén en un NAS compartido. Esto es lo que encontramos.

Estábamos compitiendo regularmente por los recursos en la unidad principal: solo había tanto ancho de banda que podía manejar. Las consultas masivas en el almacén y la carga de datos se vieron gravemente afectadas.

Necesitamos 1.5 TB para nuestro almacén (datos / índices / registros), colocamos cada uno de estos recursos en un conjunto separado de LUNS (como lo haría con el almacenamiento adjunto). Los datos abarcaban solo 10 discos. Nos encontramos con todo tipo de cuellos de botella de IO con esto. la mejor solución fue crear una gran partición en muchos discos pequeños y almacenar datos, índices y registros en el mismo lugar. Esto aceleró las cosas considerablemente.

Si está tratando con un sistema OLTP de uso moderado, podría estar bien, pero un NAS puede ser problemático.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top