web-dev-qa-db-fra.com

Lecteurs vs points de montage?

Le DBA principal précédent avait configuré des points de montage pour tous nos disques sur tous les serveurs SQL de l'entreprise. Le nouveau Senior DBA est horrifié par les points de montage veut changer notre norme (principalement, je pense, parce qu'il n'a aucune expérience avec eux).

Sur la base des résultats de nombreuses recherches sur Internet, je ne trouve aucune raison (post-SQL Server 2000) de ne pas utiliser de points de montage.

Quelqu'un connaît-il les limitations du système d'exploitation Windows concernant ce sujet?

  • J'ai récemment entendu dire que "l'OS ne reconnaît pas les points de montage". (Faux, sur la base de mes recherches sur les versions de Windows Server que nous utilisons).

Existe-t-il une raison fondée sur des preuves ou sur l'expérience de NE PAS utiliser de points de montage avec SQL Server?

  • Supposons que le manque de lettres de lecteur ne soit pas un problème pour nous.

Je crois comprendre que les points de montage sont extrêmement utiles pour séparer les charges de travail.

Quelqu'un peut-il confirmer ou réfuter ma compréhension que les points de montage séparent/isolent réellement les charges de travail des différents types de données et de fichiers journaux (fichiers de base de données système, fichiers de base de données utilisateur, tempDB) plus efficacement qu'un lecteur chacun pour les fichiers de données, les fichiers journaux et tempdb ?

12
SQL_Underworld

Cela dépend de ce qui se trouve à l'autre extrémité du point de montage. Si les montages sont tous des LUN répartis sur les mêmes disques physiques, alors aucun gain. Si les LUN sont sur un canal iSCSI partagé, lent, peut-être aucun gain. Si les LUN sont tous sous 1 contrôleur ... vous voyez combien de variables sont en jeu. Il n'y a pas de réponse unique.

Pour déterminer la configuration des points de montage, voir Locating Mount Points Using PowerShell by Boe Prox.


SQL Server n'a aucun problème avec les points de montage. Ceux-ci sont définis au niveau du système d'exploitation et SQL Server "ne sait pas1"ils ne sont pas le même volume que le lecteur dans lequel ils semblent être montés.

Certains outils de surveillance peuvent cependant vous donner de mauvaises informations sur la base de cette dernière phrase.

Par exemple, si vous avez trois points de montage comme

  1. C:\SQLData\SQL_Data où tous vos fichiers .MDB sont stockés
  2. C:\SQLData\SQL_Logs où tous vos fichiers .LDF sont stockés
  3. C:\SQLData\SQL_Backups où tous vos fichiers de sauvegarde .BAK et .TRN sont stockés

Ensuite, SQL Server fonctionnera sans aucun problème. Mais si vous exécutez une sorte d'outil qui vous avertit lorsque les disques manquent d'espace, il peut vérifier le C: et non les volumes montés en dessous, donc vous ne savez peut-être pas quand ces points de montage manque d'espace disque. De plus, diverses requêtes de "meilleures pratiques" lanceront de faux avertissements vous indiquant que vous ne devriez pas avoir toutes vos données, journaux et sauvegardes sur le même disque car SQL Server pense qu'ils sont sur le même disque. Ce sont de faux indicateurs et peuvent être ignorés.

Mais vous voudriez essentiellement configurer quelques étapes supplémentaires dans la surveillance de votre serveur pour vous assurer que le lecteur C: a suffisamment d'espace et que chaque point de montage en a aussi.

Les fois où j'ai utilisé des points de montage dans SQL Server, c'est le seul problème que j'ai rencontré: rapports d'intégrité du système SQL Server qui fournissent de fausses données sur l'espace libre disponible et de fausses erreurs disant que vous ne devriez pas avoir toutes vos données sur le même lecteur. Puisque vous savez que ce sont de fausses erreurs, elles sont assez faciles à ignorer.


1 SQL Server possède des données qui lui permettent de connaître le point de montage, mais d'un point de vue pratique, il n'y a aucune différence de comportement. Cela "fonctionne tout simplement", faisant confiance au système d'exploitation pour gérer les détails. Tout comme il fait confiance au système d'exploitation pour gérer les spécificités des LUN iSCSI qui sont connectés en tant que lecteurs locaux.

13
CaM

Sur la base des résultats de nombreuses recherches sur Internet, je ne trouve aucune raison (post-SQL Server 2000) de ne pas utiliser de points de montage.

La raison principale est que quelqu'un a eu une mauvaise expérience avec eux (ou, inversement, aucune expérience avec eux) et les a complètement éliminés ... pour toujours. Ceci est autrement connu sous le nom de préférence personnelle.

Maintenant, il y a sont quelques raisons pour lesquelles vous ne pouviez pas les utiliser. La principale raison pour laquelle je peux penser est qu'un pilote ou une application/un outil tiers (pensez au pilote de filtre, à la réplication de disque, etc.) ne le prend pas en charge. Un exemple rapide de ceci est un outil de réplication de disque de niveau bloc qui ne supportait rien d'autre que NTFS, avec seulement des tailles de cluster spécifiques et ne pouvait pas dépasser 2 TB pour un volume spécifique).

Quelqu'un connaît-il les limitations du système d'exploitation Windows concernant ce sujet?

Non, vous pouvez créer de nombreux points de montage. En fait, vous aurez généralement un problème avec les interfaces de votre appareil avant d'atteindre une limite appréciable à l'intérieur de Windows Server (en supposant que vous n'utilisez pas une version de Windows Server qui a plus de 17 ans ...).

• J'ai récemment entendu dire que "l'OS ne reconnaît pas les points de montage". (Faux, sur la base de mes recherches sur les versions de Windows Server que nous utilisons).

Si le système d'exploitation ne reconnaît pas les points de montage, comment pourrait-il même vous permettre d'utiliser un point de montage? Cela n'a aucun sens.

Si le système d'exploitation ne reconnaît pas les points de montage, pourquoi serait-il les suivre et interroger leurs métadonnées ? Veuillez également noter qu'un point de montage est une construction du système de fichiers qu'un système d'exploitation peut ou non prendre en charge. Tous les systèmes de fichiers que vous rencontrez ne prennent pas en charge les points de montage, mais le système de fichiers le plus courant dans Windows Server est NTFS qui prend en charge les points de montage et il le fait depuis un certain temps.

Juste pour ramener encore plus loin cet article faux; Windows Clustering a quelque chose appelé Cluster Shared Volumes (CSV) qui utilise en fait des points de montage pour les volumes ... c'est un élément natif utilisant la technologie. Je dois dire que quiconque vous a dit que cela doit être éduqué sur la question.

Existe-t-il une raison fondée sur des preuves ou sur l'expérience de NE PAS utiliser de points de montage avec SQL Server?

Oui, il y a toujours un serveur exécutant Windows NT 4 ... ne l'utilisez pas là. Vous pouvez également vous assurer que vous exécutez une version prise en charge de Windows Server et que vous restez à jour avec les mises à jour.

Cependant, comme je l'ai décrit ci-dessus, il peut y avoir des éléments tiers qui ne sont pas pris en charge ou qui ne fonctionnent pas correctement avec eux. Je dirais de laisser tomber ce fournisseur et d'en trouver un nouveau.

Je crois comprendre que les points de montage sont extrêmement utiles pour séparer les charges de travail.

Les points de montage sont tout simplement incroyablement utiles. Il existe de nombreuses façons de les utiliser, la plus courante consiste à contourner les limitations de lettre de lecteur (comme dans, il n'y en a que beaucoup) de Windows. La prochaine utilisation la plus courante consiste à avoir des disques de taille gérable plus petits (pensez aux LUN, au disque virtuel [VMDK, VHDX]) pour vous aider à vous éloigner des volumes monolithiques incroyablement grands et rarement gérables (il devient vraiment difficile de gérer les disques dans la plage de 10 To comme un seul LUN, disque virtuel, etc.) en particulier sur les anciennes versions de NTFS où l'implémentation était inférieure à l'utilisation possible ... par exemple, dans les anciennes versions de Windows, la taille maximale de NTFS était de 2 To.

La séparation de la charge de travail est une autre excellente utilisation. Vous pouvez certainement le voir, il existe de nombreuses utilisations et cela dépend de votre cas d'utilisation individuel. Il y a aussi impropre façons de l'utiliser ... comme faire une déclaration générale que tout doit être un point de montage. C'est juste des frais administratifs fous à ce stade.

8
Sean Gallardy

En plus de réponse de CM_Dayton et réponse de Sean Gallardy, un problème non encore identifié avec les points de montage est lié à la sécurité. Pour citer Instructions pour la définition des autorisations SQL sur les dossiers de points de montage :

Bien que les dossiers racine du point de montage puissent ressembler à des dossiers normaux et soient accessibles de la même manière que les dossiers, ils ne sont pas des dossiers normaux. Par conséquent, lorsque vous définissez des autorisations sur un dossier racine de point de montage, les autorisations ne sont pas héritées du "volume parent" de la même manière que les dossiers ordinaires. En fait, ils ne sont pas hérités du tout. En effet, bien qu'il semble que le volume monté soit un enfant du "volume parent", ce n'est pas le cas. Vous accédez simplement au volume monté via un chemin à partir du "volume parent".

En résumé, vous devez attribuer des autorisations aux dossiers de montage différemment si vous souhaitez utiliser le dossier racine du point de montage. Au lieu d'attribuer des autorisations comme vous le feriez avec un dossier normal, vous devez attribuer des autorisations sur le volume. Encore une fois, à partir de ce même article (la mise en évidence est celle de Microsoft):

Gotchas

Malheureusement, il est toujours possible de définir/afficher les autorisations sur le dossier racine du point de montage via l'Explorateur Windows, ce qui peut conduire à des résultats inattendus car les autorisations du dossier racine du point de montage peuvent sembler valides et vous pouvez voir les autorisations héritées "correctes" , cependant, ce ne sont pas les autorisations appliquées au volume monté.

Lignes directrices

  1. Il est recommandé de ne placer aucun fichier directement dans le dossier racine du point de montage . Cela rendra la gestion des autorisations beaucoup plus simple, car la tendance est de toujours vérifier les autorisations du dossier, ce qui est trompeur dans ce cas. À la place, créez un sous-dossier sous le dossier racine du point de montage et définissez les autorisations appropriées sur ce sous-dossier . Étant donné que le sous-dossier est un dossier normal, les autorisations de dossier que vous observez et définissez sont en effet les autorisations appliquées. Donc, en utilisant l'exemple précédent, vous souhaitez créer un nouveau dossier: D:\FolderForVol3 ** SubfolderXYZ **. Maintenant, définissez vos autorisations de dossier sur ce nouveau dossier SubfolderXYZ comme vous le feriez normalement.
  2. Si vous devez absolument placer des éléments directement dans le dossier racine du point de montage (pas l'approche recommandée), vous devrez définir des autorisations de volume, pas un dossier autorisations. Rappelez-vous que cela est dû au fait que les autorisations du dossier racine du point de montage ne sont pas les autorisations qui seront réellement définies sur le volume monté (car le dossier racine du point de montage n'est pas un vrai dossier). Vous pouvez définir les autorisations de volume comme suit:
  3. Si vous ajoutez un nouveau dossier pour SQL à utiliser, soyez conscient des autorisations requises pour l'accès SQL:

Si vous ne voulez pas tout imbriquer dans un sous-dossier sous le point de montage comme le recommande MS, la manière la plus simple pour moi d’attribuer des autorisations est via le cacls.exe utilitaire. Vous trouverez des instructions détaillées à ce sujet dans Vous ne pouvez pas appliquer d'autorisations au répertoire racine d'un volume de système de fichiers NTFS dans Windows Server 20 .

Je ne pense pas que ce soit un problème entièrement résolu pour l'instant. Cette question récente installation de SQL Server FCI avec des problèmes d'autorisations de point de montage montre que cela peut toujours se produire sur Windows 2012 avec SQL Server 2016.

En fonction de la sécurité que vous souhaitez attribuer, la commande peut varier, mais les tests sont la clé du succès, donc familiarisez-vous avec la commande avant de l'exécuter sur un point de montage en direct, car vous pouvez rapidement améliorer la sécurité si vous oubliez quelque chose d'aussi simple que le \E drapeau.

8
John Eisbrener

Les points de montage sont la voie à suivre pour les serveurs qui ont des applications partagées ou pour découper les données sur plus que les volumes D-Z typiques.

Par exemple, vous pouvez installer tous les fichiers de données, de journaux et temporaires d'une application sur le e: lecteur par exemple. E:/MP_1 peut avoir des fichiers de données pour l'entreprise A, E:/MP_2 peut avoir les fichiers journaux E:/mp_3 peut avoir des fichiers temporaires pour Business A et ainsi de suite. Ensuite, vous avez Business B sur les points de montage sur le F: Conduire. Chaque point de montage a son propre espace.

L'OS n'a absolument aucun problème avec les députés. Les clusters et Always On n'ont aucun problème avec les MP. J'ai travaillé pour une banque très connue qui avait installé la majorité de ses serveurs SQL sur des MP. Une fois que le DBA les utilise et comprend les concepts, il les propulse vers des solutions plus faciles dans les magasins qui en ont besoin.

Il a été mentionné de ne rien installer sur la racine MP. C'est vrai. Rien sur MP comme si vous n'installiez rien à la racine de D comme exemple.

Les solutions d'audit et de surveillance comme Foglight, Guardiam, EMS et PBM n'ont également aucun problème avec les points de montage.

3
Shellz