Lecteurs vs points de montage?


12

Le DBA principal précédent avait configuré des points de montage pour tous nos disques sur chaque serveur SQL de l'entreprise. Le nouveau Senior DBA est horrifié par les points de montage qui veut changer notre standard (principalement, je pense, car 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 ?


Le stockage physique est largement abstrait lorsque l'on utilise un SAN. Que vous utilisiez une lettre de lecteur ou un point de montage, vous devez travailler avec des administrateurs de stockage pour fournir un LUN avec les caractéristiques nécessaires. Ni SQL Server ni le système d'exploitation n'auront connaissance de la configuration sous-jacente, bien que vous puissiez installer des outils de fournisseur pour assurer la visibilité.
Dan Guzman

Réponses:


13

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 Localisation des points de montage à l'aide de PowerShell par 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 pas 1 " n'est pas le même volume que le lecteur dans lequel ils semblent être montés.

Cependant, certains outils de surveillance peuvent 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 , de sorte que vous ne savez peut-être pas quand ces points de montage manquent d'espace disque. En outre, diverses requêtes de «meilleures pratiques» émettront 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 se trouvent sur le même disque. Ce sont de faux drapeaux et peuvent être ignorés.

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

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 pas de différence de comportement. Cela «fonctionne tout simplement», en 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 connectés en tant que lecteurs locaux.


2
Je ne sais pas s'il y a toujours un problème d'installation SQL et d'ACL autour des points de montage à la racine d'un lecteur, mais cela vaut probablement la peine de les placer dans un dossier de points de montage au cas où. Ex: C: \ SQLMountPoints \ SQL_Data, C: \ SQLMountPoints \ SQL_log
Nic

Vrai. La seule fois où je l'ai fait de cette façon, j'avais un dossier "SQLDATA", puis des points de montage "data", "Log" et "backup" en dessous. Ou quelque chose à cet effet.
CaM

8

En plus de CM_Dayton de la réponse et de Sean Gallardy réponse , une question non encore identifiés avec des points de montage est lié à la sécurité. Pour citer des 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 un mot, 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é.

Des 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 de 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 des autorisations de dossier. 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 des 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 façon dont je trouve plus facile d'attribuer des autorisations est via l' cacls.exeutilitaire. 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 2003 .

Je ne pense pas que ce soit un problème entièrement résolu pour l'instant. Cette récente question d' 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.

Selon la sécurité que vous souhaitez attribuer, la commande peut varier, mais les tests sont la clé du succès, alors 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 l' \Eindicateur.


L'ancien DBA senior n'était pas au courant de ce problème de sécurité (ack!) Et je n'étais pas non plus avant ce poste. Je vais mettre sur pied une requête CMS pour trouver tous les fichiers db concernés. Cacls semble être un bon itinéraire (même si je vais chercher quelque chose basé sur PoSh). @JohnEisbrener - avez-vous rencontré des problèmes pour définir les ACL sur les fichiers db lorsqu'ils sont verrouillés en utilisation exclusive? Si oui, quelle est la prochaine étape?
SQL_Underworld

1
@SQL_Underworld, je recommanderais de faire quoi que ce soit avec cacls pendant une fenêtre de maintenance, pendant laquelle vous pouvez mettre l'instance de base de données hors ligne. Bien que cela ne soit probablement pas nécessaire , cela réduira le nombre de variables qui pourraient se produire.
John Eisbrener

8

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 principale raison 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 des raisons pour lesquelles vous ne pouvez 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 To 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 les suivrait-il et interrogerait-il 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 existe également des moyens inappropriés de l'utiliser ... comme faire une déclaration générale selon laquelle tout doit être un point de montage. C'est juste des frais administratifs fous à ce stade.


3

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 DZ typiques.

Par exemple, vous pouvez installer toutes les données d'une application, les fichiers journaux et les fichiers temporaires sur le e:lecteur par exemple. E:/MP_1peut avoir des fichiers de données pour Business A, E:/MP_2peut avoir les fichiers journaux E:/mp_3peut avoir des fichiers temporaires pour Business A et ainsi de suite. Ensuite, vous avez Business B sur les points de montage sur le F:lecteur. 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 root MP comme vous n'installeriez rien à la racine de D par 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.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.