¿Unidades frente a puntos de montaje?

El DBA Senior anterior configuró puntos de montaje para todas nuestras unidades en todos los SQL Server de la empresa. El nuevo DBA Senior está horrorizado por los puntos de montaje que quieren cambiar nuestro estándar (principalmente, creo, porque no tiene experiencia con ellos).

Según los resultados de numerosas búsquedas en Internet, no puedo encontrar ninguna razón (posterior a SQL Server 2000) para no usar puntos de montaje.

¿Alguien sabe de las limitaciones del sistema operativo Windows con respecto a este tema?

• Últimamente escuché mucho la afirmación de que "el sistema operativo no reconoce los puntos de montaje". (No es cierto, según mi investigación sobre las versiones de Windows Server que utilizamos).

¿Hay alguna razón basada en la evidencia o la experiencia para NO usar puntos de montaje con SQL Server?

• Suponga que quedarse sin letras de unidad no es un problema para nosotros.

Entiendo que los puntos de montaje son increíblemente útiles para segregar cargas de trabajo.

¿Alguien puede confirmar o refutar mi entendimiento de que los puntos de montaje en realidad segregan / aíslan las cargas de trabajo de los diferentes tipos de datos y archivos de registro (archivos de base de datos del sistema, archivos de base de datos de usuario, tempDB) de manera más eficiente que una unidad para archivos de datos, archivos de registro y tempdb ?

Depende de lo que esté en el otro extremo del punto de montaje. Si los montajes son todos LUNS distribuidos en las mismas unidades físicas, entonces no hay ganancias. Si los LUNS están en un canal iSCSI compartido, lento, quizás no haya ganancias. Si los LUNS están todos bajo 1 controlador ... verá cuántas variables están en juego. No hay una respuesta

Para determinar la configuración de los puntos de montaje, consulte Localización de puntos de montaje mediante PowerShell de Boe Prox.

SQL Server no tiene problemas con los puntos de montaje. Estos se definen en el nivel del sistema operativo y SQL Server "no sabe ¹ " no tienen el mismo volumen que la unidad en la que parecen estar montados.

Sin embargo, algunas herramientas de Monitoreo pueden brindarle información incorrecta basada en esa última oración.

Por ejemplo, si tiene tres puntos de montaje como

1. C:\SQLData\SQL_Data donde se almacenan todos sus archivos .MDB
2. C:\SQLData\SQL_Logs donde se almacenan todos sus archivos .LDF
3. C:\SQLData\SQL_Backups donde se almacenan todos sus archivos de copia de seguridad .BAK y .TRN

Entonces SQL Server funcionará sin ningún problema. Pero si ejecuta algún tipo de herramienta que le advierte cuando los discos tienen poco espacio, puede verificar el C: y no los volúmenes montados debajo de él , por lo que es posible que no sepa cuándo esos puntos de montaje tienen poco espacio en el disco. Además, varias consultas de "mejores prácticas" arrojarán advertencias falsas que le indicarán que no debe tener sus datos, registros y copias de seguridad en el mismo disco porque SQL Server cree que están en el mismo disco. Esas son banderas falsas y pueden ignorarse.

Pero básicamente querría configurar algunos pasos adicionales en la supervisión de su servidor para asegurarse de que la unidad C: tenga suficiente espacio y que cada punto de montaje también lo haga.

Las veces que he usado puntos de montaje en SQL Server, ese ha sido el único problema con el que me he encontrado: informes de estado del sistema de SQL Server que brindan datos falsos sobre el espacio libre disponible y errores falsos que dicen que no debería tener todos sus datos en el mismo disco. Como sabe que son errores falsos, es bastante fácil ignorarlos.

¹ SQL Server tiene datos que lo hacen consciente del punto de montaje, pero desde un punto de vista de uso práctico, no hay diferencia en el comportamiento. "Simplemente funciona", confiando en el sistema operativo para manejar los detalles. Del mismo modo que confía en el sistema operativo para manejar los detalles de los iSCSI LUN que están conectados como unidades locales.

Además de CM_Dayton de respuesta y de Sean Gallardy respuesta , una cuestión aún no identificado con puntos de montaje está relacionada con la seguridad. Para citar pautas para establecer permisos de SQL en carpetas de punto de montaje :

Aunque las carpetas raíz del punto de montaje pueden parecer carpetas normales y se accede a ellas de la misma manera que se accede a las carpetas, no son carpetas normales. Como resultado, cuando establece permisos en una carpeta raíz de punto de montaje, los permisos no se heredan del "volumen principal" de la misma manera que las carpetas normales. De hecho, no se heredan en absoluto. Esto se debe a que, aunque parece que el volumen montado es un elemento secundario del "volumen principal", no lo es. Simplemente está accediendo al volumen montado a través de una ruta desde el "volumen principal".

En pocas palabras, debe asignar permisos a las carpetas de montaje de manera diferente si desea utilizar la carpeta raíz del punto de montaje. En lugar de asignar permisos como lo haría con una carpeta normal, debe asignar permisos en el volumen. Nuevamente, del mismo artículo (el resaltado es de Microsoft):

Gotchas

Desafortunadamente, todavía es posible establecer / ver permisos en la carpeta raíz del punto de montaje a través del Explorador de Windows, lo que puede conducir a resultados inesperados porque los permisos de la carpeta raíz del punto de montaje pueden parecer válidos y puede ver los permisos heredados "adecuados" , sin embargo, estos no son los permisos aplicados al volumen montado.

• https://connect.microsoft.com/SQLServer/feedback/details/569895/installation-of-sql-server-2008-r2-on-mount-points-fails

Pautas

1. Se recomienda que no coloque ningún archivo directamente en la carpeta raíz del punto de montaje . Esto hará que la administración de permisos sea mucho más simple, porque la tendencia es verificar siempre los permisos de la carpeta, lo que en este caso es engañoso. En su lugar, cree una subcarpeta debajo de la carpeta raíz del punto de montaje y establezca los permisos adecuados para esa subcarpeta . Dado que la subcarpeta es una carpeta normal, los permisos de carpeta que observa y establece son los permisos que se aplican. Entonces, utilizando el ejemplo anterior, desearía crear una nueva carpeta: D: \ FolderForVol3 ** SubfolderXYZ **. Ahora, configure los permisos de su carpeta en esa nueva carpeta SubfolderXYZ como lo haría normalmente.
2. Si absolutamente debe colocar elementos directamente en la carpeta raíz del punto de montaje (no es el enfoque recomendado), entonces deberá establecer permisos de volumen, no permisos de carpeta. Recuerde que esto se debe a que los permisos de la carpeta raíz del punto de montaje no son los permisos que realmente se establecerán en el volumen montado (porque la carpeta raíz del punto de montaje no es una carpeta real). Puede establecer permisos de volumen de la siguiente manera:
   • Inicio-> ejecutar-> diskmgmt.msc (Ver las propiedades de un volumen http://technet.microsoft.com/en-us/library/cc740097.aspx )
   • Seleccione el volumen-> Propiedades-> pestaña Seguridad
3. Si está agregando una nueva carpeta para que SQL la use, tenga en cuenta los permisos necesarios para el acceso a SQL:
   • A partir de SQL Server 2012, los permisos se asignan al SID por servicio para cada uno de sus servicios. http://msdn.microsoft.com/en-us/library/jj219062.aspx
   • Configurar cuentas de servicio de Windows y permisos http://msdn.microsoft.com/en-us/library/ms143504.aspx

Si no desea anidar todo en una subcarpeta debajo del punto de montaje como recomienda MS, la forma en que me resulta más fácil asignar permisos es a través de la cacls.exeutilidad. Puede encontrar instrucciones detalladas para ello en No puede aplicar permisos al directorio raíz de un volumen de sistema de archivos NTFS en Windows Server 2003 .

No creo que sea un problema completamente resuelto todavía. Esta pregunta reciente La instalación de SQL Server FCI con problemas de permisos de Mount Point muestra que todavía puede suceder en Windows 2012 con SQL Server 2016.

Dependiendo de la seguridad que desee asignar, el comando puede variar, pero la prueba es clave para el éxito, así que familiarícese con el comando antes de ejecutarlo contra un punto de montaje en vivo, ya que puede descifrar rápidamente la seguridad si olvida algo tan simple como la \Ebandera.

Según los resultados de numerosas búsquedas en Internet, no puedo encontrar ninguna razón (posterior a SQL Server 2000) para no usar puntos de montaje.

La razón principal es que alguien tuvo una mala experiencia con ellos (o, por el contrario, ninguna experiencia con ellos) y los ha eliminado por completo ... para siempre. Esto se conoce como preferencia personal.

Ahora, no son algunas razones por las que no se podía utilizar. La razón principal por la que puedo pensar es que un controlador o aplicación / herramienta de terceros (piense en el controlador de filtro, la replicación de disco, etc.) no lo admite. Un ejemplo rápido de esto es una herramienta de replicación de disco a nivel de bloque que no admitía nada más que NTFS, con solo tamaños de clúster específicos y no podía superar los 2 TB para ningún volumen específico.

¿Alguien sabe de las limitaciones del sistema operativo Windows con respecto a este tema?

No. puedes hacer muchos, muchos puntos de montaje. De hecho, generalmente tendrá un problema con las interfaces de su dispositivo antes de alcanzar cualquier límite apreciable dentro de Windows Server (suponiendo que no esté utilizando una versión de Windows Server que tenga más de 17 años ...).

• Últimamente escuché mucho la afirmación de que "el sistema operativo no reconoce los puntos de montaje". (No es cierto, según mi investigación sobre las versiones de Windows Server que utilizamos).

Si el sistema operativo no reconoce los puntos de montaje, entonces, ¿cómo le permitiría usar un punto de montaje? Eso no tiene sentido.

Si el sistema operativo no reconoce los puntos de montaje, ¿por qué los rastrearía y consultaría sus metadatos ? Además, tenga en cuenta que un punto de montaje es una construcción del sistema de archivos que un SO puede admitir o no. No todos los sistemas de archivos con los que se encuentra pueden admitir puntos de montaje, sin embargo, el sistema de archivos más común en Windows Server es NTFS, que de hecho admite puntos de montaje y lo ha sido por un tiempo.

Solo para llevar este artículo falso a casa aún más; Windows Clustering tiene algo llamado Cluster Shared Volumes (CSV) que en realidad usa puntos de montaje para los volúmenes ... ese es un elemento nativo que usa tecnología. Tengo que decir que cualquiera que le haya dicho esto debe ser educado en el tema.

¿Hay alguna razón basada en la evidencia o la experiencia para NO usar puntos de montaje con SQL Server?

Sí, siempre existe ese servidor que ejecuta Windows NT 4 ... no lo use allí. También puede asegurarse de estar ejecutando una versión compatible de Windows Server y mantenerse actualizado con las actualizaciones.

Sin embargo, como describí anteriormente, puede haber elementos de terceros que no son compatibles o no funcionan correctamente con ellos. Yo diría que abandone ese proveedor y encuentre uno nuevo.

Entiendo que los puntos de montaje son increíblemente útiles para segregar cargas de trabajo.

Los puntos de montaje son increíblemente útiles. Hay muchas formas de usarlas, la más común es evitar las limitaciones de las letras de unidad (como en el caso, solo hay muchas) de Windows. El siguiente uso más común es tener unidades de tamaño manejable más pequeñas (piense en LUN, disco virtual [VMDK, VHDX]) para ayudar a escapar de volúmenes de monolitos increíblemente grandes y raramente manejables (realmente se convierte en un problema administrar unidades en el rango de 10TB como un solo LUN, disco virtual, etc.) especialmente en versiones anteriores de NTFS donde la implementación era menor que el uso posible ... por ejemplo, en versiones anteriores de Windows, el tamaño máximo de NTFS era de 2 TB.

La segregación de la carga de trabajo es otro gran uso. Definitivamente puede ver, hay muchos usos y depende de su caso de uso individual. También hay formas inadecuadas de usarlo ... como hacer una declaración general de que todo debe ser un punto de montaje. Eso es una locura administrativa loca en ese punto.

Los puntos de montaje son el camino a seguir para servidores que tienen aplicaciones compartidas o para dividir datos en más que solo los volúmenes DZ típicos.

Por ejemplo, puede instalar todos los datos de aplicaciones, archivos de registro y temporales en la e:unidad, por ejemplo. E:/MP_1puede tener archivos de datos para el Negocio A, E:/MP_2puede tener los archivos de registro E:/mp_3puede tener archivos temporales para el Negocio A y así sucesivamente. Luego tiene Business B en los puntos de montaje en la F:unidad. Cada punto de montaje tiene su propio espacio.

El sistema operativo no tiene absolutamente ningún problema con los parlamentarios. Clusters y Always On no tienen problemas con los MP. Trabajé para un banco muy conocido que tenía la mayoría de sus servidores SQL instalados en MP. Una vez que el DBA los use y comprenda los conceptos, los impulsará a soluciones más fáciles en las tiendas que lo necesitan.

Se mencionó no instalar nada en la raíz MP. Eso es correcto. Nada en MP root como usted no instalaría nada en la raíz de D como ejemplo.

Las soluciones de auditoría y monitoreo como Foglight, Guardiam, EMS y PBM tampoco tienen problemas con los puntos de montaje.